Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bindings in catch/finally blocks of computation expressions #853

Open
5 tasks done
Horusiath opened this issue Mar 18, 2020 · 2 comments
Open
5 tasks done

Bindings in catch/finally blocks of computation expressions #853

Horusiath opened this issue Mar 18, 2020 · 2 comments

Comments

@Horusiath
Copy link

Horusiath commented Mar 18, 2020

I propose we add support for bindings in catch/finally blocks of computations expressions, eg.:

let doWork () = task {
   try
     return! doSomething ()
   finally
     do! doSomethingElse()   // this is not supported by the compiler right now
}

Another related problem is that there's no equivalent of C# await using and in current state of the compiler it's impossible to create non-blocking one by yourself, as IAsyncDisposable would require bind in a finally block (see above).

Affidavit (please submit!)

Please tick this 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
  • I have searched both open and closed suggestions on this site and believe this is not a duplicate
  • 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.

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 with a help of a mentor.
@dsyme
Copy link
Collaborator

dsyme commented Oct 27, 2022

Approving this. We should look for a method such as TryFinallyMonadic or similar (not sure of the best name, it doesn't matter too much) and use that with the richer signature.

@jwosty
Copy link
Contributor

jwosty commented Aug 17, 2023

Isn't this essentially the same as #651?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants