Support do! ... and! ...

[cmeeren]

I propose we add support for do! ... and! ... in computation expressions.

Consider this imagined example using validation from FsToolkit.ErrorHandling (like result, but with applicative combination of a list of errors):

let getOrderSummary user category =
    validation {
        do! user.CanShowOrders |> Result.requireTrue UnauthorizedOrderSummary
        and! user.AllowedCategories.Contains category |> Result.requireTrue UnauthorizedCategory
        return getOrderSummary' category
    }

The existing way of approaching this problem in F# is using let! _ = ... and! _ = ...:

let getOrderSummary user category =
    validation {
        let! _ = user.CanShowOrders |> Result.requireTrue UnauthorizedOrderSummary
        and! _ = user.AllowedCategories.Contains category |> Result.requireTrue UnauthorizedCategory
        return getOrderSummary' category
    }

Pros and Cons

The advantages of making this adjustment to F# are more natural/intuitive syntax.

The disadvantages of making this adjustment to F# are none, as far as I can see. This seems to me to be an intuitive syntax. YMMV.

Extra information

Estimated cost (XS, S, M, L, XL, XXL): Don't really know. S/M?

Related suggestions: (put links to related suggestions here)

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.

[cmeeren]

Note that it I think this should be able to be combined with and! _, though admittedly it does not look great because of the initial do!:

let getOrderSummary user category =
    validation {
        do! user.CanShowOrders |> Result.requireTrue UnauthorizedOrderSummary
        and! user.AllowedCategories.Contains category |> Result.requireTrue UnauthorizedCategory
        and! foo = user.Foo |> Result.requireSome MissingFoo
        return getOrderSummary' category foo
    }

This makes me slightly doubt my suggestion.

[Lanayx]

Isn't it already supported? https://learn.microsoft.com/en-us/dotnet/fsharp/language-reference/computation-expressions#and

[cmeeren]

let! ... and! ... is supported, not do! ... and! ....

[brianrourkeboll]

For what it's worth, this is what the original RFC for and! says on the subject:

We chose not to support do! or anddo! in place of a let! _ = ... or and! _ = ... (respectively), since do! implies side-effects and hence sequencing in a way that applicatives explicitly aim to avoid (see the parallelism example earlier). These keywords and their corresponding translations could be introduced in a later addition to the language, if the community's position changed on the matter.

The comment about do! implying side effects doesn't apply to your validation example, of course. I have also myself seen codebases that heavily used let! () = … and! () = … for side-effect-free applicative validation, for a similar reason (I am guessing) to your example: to validate untrusted objects created via, e.g., automatic deserialization, auto-mapping from a database schema, etc.

I would personally normally try to use a "parse, don't validate" approach where possible — in one of the codebases I'm thinking of, the deserialization already had a manual mapping step anyway, and the "validation" could have just been done there as (applicative) "parsing" to begin with. The number of lines of code for validating (let! () = … and! () = …) or for parsing and mapping (let! x = … and! y = …) is going to be pretty similar anyway.

And even when there is a good reason not to use the "parse, don't validate" approach (e.g., perf overhead, DTOs known to be always identical to domain types for the lifetime of the codebase, etc.), I personally think that the existing let! () = … and! () = … syntax does a better job of:

1. Showing that no meaningful value is being returned from each validation function in the success case, while
2. Not necessarily implying side effects, which the do! in do! … and! … kind of does.

Indeed, do outside of computation expressions is basically never useful for anything but side effects, with very few exceptions, e.g., as a place to put an assembly-level attribute ([<assembly: SomeAttribute>] do ()).

[abelbraaksma]

I think this is generally a good suggestion. Another use case may be where people want to create a bunch of tasks and execute them in parallel (this has been suggested for let! ... and! as well).

I'd like to propose, however, to use the do! ... anddo!... syntax instead. I think it helps with parsing (both human visual parsing, and machine parsing). I also don't think it is a good idea to use the same keyword for assignment and the absence of assignment.

[Tarmil]

As a variant proposal, and do! would have the advantage of not introducing a new keyword.