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

[Developer]

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) 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.  For now, I won't make those demands.

~Robert Widmann

2016/01/26 12:40、Greg Titus via swift-evolution <swift-evolution at swift.org> のメッセージ:

> 
>>> On Jan 26, 2016, at 9:30 AM, Developer via swift-evolution <swift-evolution at swift.org> wrote:
>>> 
>>> - occasionally: a rather poorly-named, 2-way sum type (poorly-named b/c its convention won’t generalize to 3-way sums, or 4-ways sums, etc.)
>> 
>> Good thing Either<Either<...>, Either<...>> works.
> 
> This is another example of exactly why Either is terrible in practice. I understand that from a type algebra point of view this is perfectly reasonable and clean and that a 2-way sum is all that is necessary because larger sums are easily created by construction. Type theory-wise it’s lovely.
> 
> But from a literate programming point of view, when will "case let .Left(.Left(a)): case let .Left(.Right(b)): case let .Right(.Left(c)): case let .Right(.Right(d)): “ ever be the most understandable way to express _anything_ in Swift? And why would we want to encourage such things?
> 
> 	- Greg
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160126/96ae4746/attachment.html>