<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>And as I've said before, if you must generalize to higher amounts of cases, you must acknowledge the inclusion-exclusion principle (<a href="https://en.m.wikipedia.org/wiki/Inclusion–exclusion_principle">https://en.m.wikipedia.org/wiki/Inclusion–exclusion_principle</a>) 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. </div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">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.<br><br>~Robert Widmann</div><div><br>2016/01/26 12:40、Greg Titus via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> のメッセージ:<br><br></div><blockquote type="cite"><div><meta http-equiv="Content-Type" content="text/html charset=utf-8"><br class=""><div><blockquote type="cite" class=""><div class="">On Jan 26, 2016, at 9:30 AM, Developer via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><div class=""><div dir="auto" class=""><div class=""><div class=""><div class=""><div class=""><br class=""><blockquote type="cite" class=""><div class=""><font class=""><span style="background-color: rgba(255, 255, 255, 0);" class="">- 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.)</span></font></div></blockquote><div class=""><br class=""></div><div class="">Good thing Either<Either<...>, Either<...>> works.</div></div></div></div></div></div></div></blockquote><br class=""></div><div>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.</div><div><br class=""></div><div>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?</div><div><br class=""></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>- Greg</div></div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></body></html>