Allow results of match! to be bound

[et1975]

Allow results of match! to be bound

Currently binding the results of match! reintroduces quite a bit of noise.
Quoting from the conversation in the implementation:

So
let (Some x) = syncX
becomes
let x = match syncX with Some x -> x | None -> fail()
and
let! (Some x) = asyncX
becomes
let! x = async { match! asyncX with Some x -> return x | None -> fail() }
I suppose we could in theory allow ! computations on the r.h.s. of a let and I don't think it would be a breaking change - just a little odd because the let is really a bind.

Ideally, I think it would look like this:
let x = match! asyncX with Some x -> x | None -> fail()

Pros and Cons

The advantages of making this adjustment to F# are

• Symmetry with match
• Code that encounters this type of annoyance would be a little cleaner
• Non-invasive and simple

The disadvantages of making this adjustment to F# are ...

• Nonzero effort required :P
• Maybe an instance of a bigger idris-style inline bind

Extra information

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

Related suggestions: #572

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

[jwosty]

I see the issue, but I don't see any nice solutions to this. The possibility of just allowing one to write:

let x =
    match! x with | Some -> ... | None -> ...

Just feels super dirty and just not right to me: it breaks the consistency of let and let!. The only other way to address this that I can think of would be to introduce a construct that acts like a match! but lets you bind the result to a name as well... Going on a bit of a tangent here, but maybe let could be extended to handle multiple cases at once? I'm really not sure how to handle this.

[kspeakman]

I run into this lately. Especially when I need to tag the result of a side effect. Here are the two ways to accomplish it that I could think of.

Note: This is used in the effectful part of my code.

Nested Async as mentioned above

        match effect with
        | EnsurePositionTableExists ->
            async {
                let! result =
                    async {
                        match! Sql.write sqlConfig PositionTrackerSql.ensureExists with
                        | Ok () ->
                            return Ok ()
                        | Error ex ->
                            log.LogCritical("{@Effect} failed {@Ex}", effect, ex)
                            return Error ()
                    }
                return PositionTableExists result
            }
        ...

Repeat tag in each branch

        match effect with
        | EnsurePositionTableExists ->
            async {
                match! Sql.write sqlConfig PositionTrackerSql.ensureExists with
                | Ok () ->
                    return PositionTableExists (Ok ())
                | Error ex ->
                    log.LogCritical("{@Effect} failed {@Ex}", effect, ex)
                    return PositionTableExists (Error ())
            }
        ...

Each of these alternatives feels wasteful in some way. Although the nested async feels worse (and should perform worse unless optimized away).

Here is how I wish I could express it:

        match effect with
        | EnsurePositionTableExists ->
            async {
                match! Sql.write sqlConfig PositionTrackerSql.ensureExists with
                | Ok () ->
                    Ok ()
                | Error ex ->
                    log.LogCritical("{@Effect} failed {@Ex}", effect, ex)
                    Error ()
                |> PositionTableExists
            }
        ...

But this includes non-related issues like eliminating gratuitous return statements and continuation with a pipe operator.

[dsyme]

Closing this old issue