[swift-evolution] Proposal: An Either Type in the STL

[John McCall]

> On Dec 9, 2015, at 3:45 PM, Guillaume Lessard via swift-evolution <swift-evolution at swift.org> wrote:
> There is probably a greater need for a non-agnostic Result monad type (with descriptive cases .Value and .Error) for manual error propagation. If it’s not agnostic then the happy and unhappy paths can be better optimized.
> 
> Such a type was proposed but not designed in <https://github.com/apple/swift/blob/master/docs/ErrorHandling.rst#manual-propagation-and-manipulation-of-errors>. Was it abandoned or simply left for later?
> (There are several implementations available on github, heh)

We considered it, had some specifics worked out, and then decided to put it on hold.  Part of our reasoning was that it seemed more like an implementation detail of the async / CPS-conversion features we’d like to provide than an independently valuable feature, given that we don’t want to encourage people to write library interfaces using functional-style error handling instead of throws.

It’s also a feature that’s directly affected by the design of typed throws, which in turn poses some usability challenges for it.  For example, without typed throws you really just want the type to be Result<T>.  With typed throws, can you still write that, or do you have to write Result<T, ErrorType>?  Also, if we want every function result signature to have a corresponding Result<> type, does that permanently prevent us to supporting multiple error types with “typed throws”?  Also, would it be too frustrating to work with typed Result values if we don’t allow implicit covariant conversions along one or both dimensions?

John.