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

[Chris Lattner]

On Jan 26, 2016, at 2:24 PM, Developer via swift-evolution <swift-evolution at swift.org> wrote:
> Okay, we’ll stop quibbling about the name (I’ll try to use “sum” from here on out), I want to focus on the first part of this because I think it’s great.  There are definitely limitations to extensions like that, but I don’t think they should impede the inclusion of the data type itself.  For one, if we’re going to focus on strong typing, then it not being usable seems a feature not a bug.  Can you think of any more in with respect to the fully-generic form?

I am also becoming more strongly opposed to this proposal the more discussion goes on.  Here’s another direction to try to convey this:

The argument is often made that we should have a generic “Either” type (though the name doesn’t matter, I’m talking about the semantics you’re describing) to complement tuples.  However, the Either type you are providing is not analogous to Swift tuples, because Swift tuples allow you to *name* the elements of the tuple, and is generic w.r.t. the number of elements.  Your Either type has neither of these features.

I agree with Kevin and others that we’re likely to be destined to introduce a real Result type.  This will serve the most common cases that you’re citing as use cases for a fully generic Either type, and provide good names.  Why should we add a type to the standard library that has very few remaining use cases, and leads to a code style that we don’t want?

-Chris