Adding a built-in computation expression for the Result type

[mardukbp]

The Result type and CEs are core features of F# and yet there is no built-in CE for Result. In this repo I could not find a suggestion for adding it to FSharp.Core. In the F# Forums and in Slack there are links to two libraries that provide this feature (and a lot more).

I assume there is a good reason why it is not already in FSharp.Core. At the same time, it is natural to want to combine both language features and it would require little effort to implement.

So, why not?

[T-Gro]

In general, FSharp.Core does not deliver builders for computation expressions that can be (sometimes even trivially) done by libraries or directly in app code.

Unlike types and abstractions, CEs compose well as long as they have the same underlying type. Therefore the users do not experience any friction when combining CEs from two competing libraries, as long as they are all operating on the same types.

If a 3rd party library or custom code can fulfill the need equally well and there is neither friction nor "ecosystem split" when more competing alternatives exist => I don't think FSharp.Core should take over.

The same applies to option{} , voption{}, asyncResult{} and likely others.

[mardukbp]

Thank you for the explanation. I appreciate that the F# team tries to keep the language and the Core library lean. However, I disagree with the position of not providing trivial functionality out of the box. Let me explain.

The documentation of the Result type only mentions pattern matching. No mention of computation expressions. With pattern matching one can quickly end up with deeply nested code that is hard to read and understand. Best case scenario, one is already familiar with CEs (or for-comprehensions or do-notation) and can write a builder or find a library that implements it. The combined time that it takes all the users who need this functionality to somehow get it far exceeds the time that it takes the F# team to write the builder and update the documentation.

And this is why I assert that this statement does not hold:

If a 3rd party library or custom code can fulfill the need equally well

There is equality of outcome, but the time and effort involved are not equal.

If FSharp.Core provided a CE builder for Result it would:

• offer a better out-of-the-box experience
• guide users to better ways to chain monads

This translates in increased productivity, code quality and knowledge. Of course, when the core functionality is not enough, then it is time to reach out for a 3rd party library or DIY.