<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 &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; 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). &nbsp;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. &nbsp;Nor is there a sufficient amount of type system magic to build the type that you wish for without an even more drastic change.&nbsp;</div><div class=""><br class=""></div><div class="">Besides, we're getting away from the fundamental use-cases of Either. &nbsp;If you have a trinary or quaternary or etc. expression, you should be using throws. &nbsp;Either is for a disjoint sum of possibilities, not recovering algebraic data types. &nbsp;If you wish to go down that road, we need to discuss more pressing changes to the type system to support it.&nbsp;</div></div></div></blockquote><br class=""></div><div>The type system already supports N-ary “either” types. &nbsp;We call them enums.</div><div><br class=""></div><div>-Chris</div><br class=""></body></html>