<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="">A tuple is a product, we want a sum here. &nbsp;A tuple says “I know I have 2 things”, a sum says “I know one or the other of these things is here but not both” without the need to unwrap both halves just to check. &nbsp;Past a certain point, you’re writing Either code over and over again without realizing it.<div class=""><br class=""></div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Dec 9, 2015, at 6:41 PM, Ilias Karim &lt;<a href="mailto:ilias.karim@gmail.com" class="">ilias.karim@gmail.com</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">What are the advantage over using a tuple? One great feature about tuples is being able to name parameters so you can dispel ambiguity.</div><div class=""><br class=""></div><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Dec 9, 2015, at 3:35 PM, Jacob Bandes-Storch &lt;<a href="mailto:jtbandes@gmail.com" class="">jtbandes@gmail.com</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">The idea of using Left/Right is to remain agnostic to what sorts of things users might want to put in. It's feasible a user might want Either&lt;Int, String&gt;, not just Either&lt;ErrorType, T&gt;.<div class=""><br class=""></div><div class="">While I'm not sure Left &amp; Right are the best choices, I don't think it's particularly worrisome when it comes to errors, as the general type-safety of the language will prevent users from mixing up success &amp; error cases.<br class=""><div class="gmail_extra"><br clear="all" class=""><div class=""><div class="gmail_signature"><div dir="ltr" class=""><div class="">Jacob<br class=""></div></div></div></div>
<br class=""><div class="gmail_quote">On Wed, Dec 9, 2015 at 3:32 PM, Ilias Karim via swift-evolution <span dir="ltr" class="">&lt;<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>&gt;</span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Robert,<br class="">
<br class="">
I agree with your recommendation of a generic Either type.<br class="">
<br class="">
However, I find your use of “Right” as the “Correct” value (whatever that means) of an instance of an Either type a little perplexing. While clever, it is exactly the kind of convention that easily leads to misunderstandings about the nature of the type itself ie. is it right and left or wrong and correct? At least that is my first impression after scanning your code.<br class="">
<br class="">
Ilias<br class="">
<div class="HOEnZb"><div class="h5"><br class="">
&gt; On Dec 9, 2015, at 3:06 PM, Developer via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; wrote:<br class="">
&gt;<br class="">
&gt; It’s high time the STL admitted some kind of disjoint union type, at the very least because it’s such a minor addition it seems a shame to leave it out.&nbsp; Whatever feelings one may have about `throws`, the lack of standardizing on a datatype representing choice has caused the community to get creative and create many disjoint implementation of the same concept over and over and over again.&nbsp; To that end, I propose the STL ship with an Either type; We at TypeLift have already got our own we’d like to model it on (<a href="https://github.com/typelift/Swiftx/blob/master/Swiftx/Either.swift#L16" rel="noreferrer" target="_blank" class="">https://github.com/typelift/Swiftx/blob/master/Swiftx/Either.swift#L16</a>).<br class="">
&gt;<br class="">
&gt;<br class="">
&gt; ~Robert Widmann (CodaFi)<br class="">
&gt; _______________________________________________<br class="">
&gt; swift-evolution mailing list<br class="">
&gt; <a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">
&gt; <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">
<br class="">
_______________________________________________<br class="">
swift-evolution mailing list<br class="">
<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">
</div></div></blockquote></div><br class=""></div></div></div>
</div></blockquote></div><br class=""></div></div></blockquote></div><br class=""></div></body></html>