<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jan 26, 2016, at 10:03 AM, Developer via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="content-type" content="text/html; charset=utf-8" class=""><div dir="auto" class=""><div class="">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%E2%80%93exclusion_principle" class="">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 class=""><br class=""></div><div class="">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. </div></div></div></blockquote><br class=""></div><div>The type system already supports N-ary “either” types. We call them enums.</div><div><br class=""></div><div>-Chris</div><br class=""></body></html>