Allow use with active patterns in Computation Expressions

[Swoorup]

I propose we allow use statements in Computation Expressions. such as follows

type PooledEntry<'a & #IDisposable>(
  entry: 'a,
  pooledSemaphore: SemaphoreSlim
)=
  member _.Entry = entry
  
  interface IDisposable with
    override _.Dispose() =
      entry.Dispose()
      pooledSemaphore.Release() |> ignore


module DeadPool =
  let (|PooledEntry|) (x: PooledEntry<_>) =
    x.Entry
    
  let testPooling () =
    let getConnectionAsync: unit -> Task<PooledEntry<IDbConnection>> = failwith ""
    let getConnection: unit -> PooledEntry<IDbConnection> = failwith ""
    
    task {
      use PooledEntry(entry) = getConnection() // compiles
      let! PooledEntry(entry) = getConnectionAsync() // compiles
      use! PooledEntry(entry) = getConnectionAsync() // compile error
      return ()
    }

The use! PooledEntry(entry) = getConnectionAsync() should compile and should be able to dispose the PooledEntry object when it is out of scope.

The compile error is: error FS0002: This function takes too many arguments, or is used in a context where a function is not expected

The existing way of approaching this problem in F# is
not to use active patterns with use statement in CE at all.

Pros and Cons

The advantages of making this adjustment to F# are

• Uniform and consistency in both CE or non-CE versions.

The disadvantages of making this adjustment to F# are

• Additional work for the lang team

Extra information

Estimated cost (XS, S, M, L, XL, XXL):
M

Affidavit (please submit!)

Please tick these items by placing a cross in the box:

• This is not a question (e.g. like one you might ask on StackOverflow) and I have searched StackOverflow for discussions of this issue
• This is a language change and not purely a tooling change (e.g. compiler bug, editor support, warning/error messages, new warning, non-breaking optimisation) belonging to the compiler and tooling repository
• This is not something which has obviously "already been decided" in previous versions of F#. If you're questioning a fundamental design decision that has obviously already been taken (e.g. "Make F# untyped") then please don't submit it
• I have searched both open and closed suggestions on this site and believe this is not a duplicate

Please tick all that apply:

• This is not a breaking change to the F# language design
• I or my company would be willing to help implement and/or test this

For Readers

If you would like to see this issue implemented, please click the 👍 emoji on this issue. These counts are used to generally order the suggestions by engagement.

[brianrourkeboll]

Don commented on allowing arbitrary patterns in use/use! here — #881 (comment) — where he also suggested opening a new suggestion for arbitrary patterns, so I guess this can serve as that.