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

[Chris Lattner]

> On Jan 25, 2016, at 10:27 PM, Developer via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Are you opposed to the name or the semantics?
> 
> I will not accept a revision that reduces the level of abstraction of the current proposal.  I will, however, accept name changes.  Result, though, I believe is out of the question.  It strongly implies a common but pointed set of semantics that discourage thinking of this type as data and more as an alternative to throws.  I do not wish to emphasize the error case, or the theoretical case, I wish to encourage the general case.  We must remember that despite Rust's success, they do not have to live alongside an exceptions mechanism like Either does.

Here is my concern:  Swift enums should be good enough that we don’t need an Either type.  If defining your own custom enum is hard or bad, then we should fix that.

There are a number of concepts floating around that would make enums better in various ways.  One specific one would be to synthesize optional accessors that line up with enum cases.

What will the advantage of Either be once enums get even more fully baked?

-Chris