Allow `use` with active patterns in Computation Expressions

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:

[x] This is not a question (e.g. like one you might ask on StackOverflow) and I have searched StackOverflow for discussions of this issue
[x] 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
[x] 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
[x] I have searched both open and closed suggestions on this site and believe this is not a duplicate

Please tick all that apply:

[x] 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 :+1: emoji on this issue. These counts are used to generally order the suggestions by engagement.

fsharp / fslang-suggestions