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

Chris Lattner clattner at apple.com
Tue Jan 26 15:30:18 CST 2016

> On Jan 26, 2016, at 10:03 AM, Developer via swift-evolution <swift-evolution at swift.org> wrote:
> And as I've said before, if you must generalize to higher amounts of cases, you must acknowledge the inclusion-exclusion principle (https://en.m.wikipedia.org/wiki/Inclusion–exclusion_principle <https://en.m.wikipedia.org/wiki/Inclusion%E2%80%93exclusion_principle>) which produces a completely different type (often called These).  There is no amount of type system magic that is going to make this generalize like that, outside of a horrendous construction on a dependently typed language.  Nor is there a sufficient amount of type system magic to build the type that you wish for without an even more drastic change. 
> Besides, we're getting away from the fundamental use-cases of Either.  If you have a trinary or quaternary or etc. expression, you should be using throws.  Either is for a disjoint sum of possibilities, not recovering algebraic data types.  If you wish to go down that road, we need to discuss more pressing changes to the type system to support it. 

The type system already supports N-ary “either” types.  We call them enums.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160126/ffd7c320/attachment.html>

More information about the swift-evolution mailing list