[swift-evolution] [proposal] Either in the Swift Standard Library

[Chris Lattner]

On Jan 27, 2016, at 7:15 PM, Kevin Ballard <kevin at sb.org> wrote:
>> To set expectations, I’d expect the Result type to be specifically designed to serve the problem domain of capturing a return value.  Even assuming we get “typed throws”, I’d expect the error argument to have an ErrorType constraint on it.  Further, if we expand the function result type model, we’d expect Result to track that.  I would also expect the Result type to have methods on it specific to its domain.
>>  
>> This means that it will not be unconstrained, and not a generic type like the Either you are proposing.
>  
> I'd prefer to have an unconstrained Result<T,E> that has extensions for E: ErrorType. I don't think there's any particular value in defining the type itself as Result<T, E: ErrorType> because most of the methods won't care about the ErrorType bounds, and the methods that we'd want to have that do care about it aren't crucial to the basic operation of the type. Having it unconstrained will also allow people to use Result<T,ErrorType> (given that existential protocol values don't conform to the protocol, although I haven't been following everything so maybe there's already plans to change that?).

I raised this for three reasons:

1) Adding an ErrorType constraint clarifies the intended usage.
2) Hopefully we’ll get more useful functionality on ErrorType at some point, making the constraint useful.
3) I wanted to make it clear that Result would not be a general Either type to drive the discussion on Either forward.

Also, not putting the constraint on the type makes extensions of Result that want the constraint more ugly to write.

That said, I’m not personally interested in debating the design of result.  We need to discuss typed throws first, and that is blocked on resilience getting nailed down.

> There's also some questions about how this would interact with "typed throws" (assuming we get typed throws), e.g. if a function can return one of 3 different error types, how would you represent this with a Result<T,E> (short of manually defining a new enum with a variant for each case), and so if we are going to get "typed throws" then it makes some sense to wait until we have some idea of how that's going to work before designing a Result type that expects to interact with errors.

FWIW, I’m in favor of typed throws, but only of a single type that conforms to ErrorType.    “throws” would be sugar for “throws ErrorType”.  The most common case I would imagine people using is “throws SomeEnum”.  I’m personally not interested in supporting “throws A,B”.

-Chris