<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="">So Either as a type is problematic because of a name… or something like that that it is either to generic or too niche…<div class=""><br class=""></div><div class="">I was wondering if we could get to it by another way that would be interoperable between libraries but have absolutely no implementation in the general library - but would be able to be tacked on through external libraries.</div><div class=""><br class=""></div><div class="">Something like:</div><div class=""><br class=""></div><div class="">typealias MyEither = Int | String &nbsp; // not sure how it would be done with generic typing. &nbsp;</div><div class=""><br class=""></div><div class="">where Either may contain an Int or a String but not both. &nbsp;</div><div class=""><br class=""></div><div class="">As well as a way for third parties to add on things (queriable somehow) like fold, map as their implementation needs. &nbsp;Maybe also be able to define postfix operators for functions that decompose or use these “Either” types without calling them “Either”.</div><div class=""><br class=""></div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 2016-01-27, at 12:52:38, Jarod Long 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="">

<title class=""></title>

<div class="">
<div name="messageBodySection" class="">I hadn't, thanks for pointing me in the right direction.<br class="">
<br class="">
Jarod</div>
<div name="messageSignatureSection" class=""><br class=""></div>
<div name="messageReplySection" class=""><br class="">
On Jan 26, 2016, 21:48 -0800, Developer &lt;<a href="mailto:devteam.codafi@gmail.com" class="">devteam.codafi@gmail.com</a>&gt;, wrote:<br class="">
<blockquote type="cite" class="">Have you seen the last round of discussions (root&nbsp;<a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/001394.html" class="">https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/001394.html</a>)? &nbsp;I don’t want to continue discussing this specific thing here because it is outside the scope of the proposal as it stands.
<div class=""><br class="">
<div class="">
<blockquote type="cite" class="">
<div class="">On Jan 27, 2016, at 12:46 AM, Jarod Long 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="">
<div class="">
<div name="messageBodySection" class="">FWIW, I think a preferable alternative to an Either or Result type is union types, which could work as a sort of on-the-fly enum. Silly example:<br class="">
<br class="">
func getNameOrAge() -&gt; |String, Int| { // or maybe enum(String, Int)<br class="">
&nbsp; &nbsp; if true {<br class="">
&nbsp; &nbsp; &nbsp; &nbsp; return "Butterscotch"<br class="">
&nbsp; &nbsp; } else {<br class="">
&nbsp; &nbsp; &nbsp; &nbsp; return 25<br class="">
&nbsp; &nbsp; }<br class="">
}<br class="">
<br class="">
switch getNameOrAge() {<br class="">
&nbsp; &nbsp; case String(let name): print("Name: \(name)")<br class="">
&nbsp; &nbsp; case Int(let age): &nbsp; &nbsp; print("Age: \(age)")<br class="">
}<br class="">
<br class="">
I've run into a couple situations where I've needed to return different types from some one-off function (outside of the result/error pattern), but didn't want to create another type for that hyper-specific use case, and I wished I had some way of inlining a one-off, either-or type. It's even temping to use a tuple with optional values to leverage its inlining behavior, but that produces extra unwanted code paths. Union types are a powerful and use-case-agnostic solution to that kind of problem.<br class="">
<br class="">
Jarod</div>
<div name="messageSignatureSection" class=""><br class=""></div>
<div name="messageReplySection" class=""><br class="">
On Jan 26, 2016, 21:27 -0800, Craig Cruden via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt;, wrote:<br class="">
<blockquote type="cite" class="">The other minor point is that this type (TBD) may not in fact be a result of function (of which everything returned from a function is in fact a result) would be an erroneous name.&nbsp;
<div class=""><br class="">
<div class="">
<blockquote type="cite" class="">
<div class="">On 2016-01-27, at 12:09:07, 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 style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">
<div class="">Hello all,</div>
<div class=""><br class=""></div>
<div class="">I’m going to try and round up a summary of arguments for and against this proposal and my response to them, because I think there is a clear sense in everybody’s mind what Either entails, but that sense differs widely depending on individual interactions with the parts of the proposal. &nbsp;I take full responsibility for the rhetoric and the style of debate that has been going on for the past ~24 hours. &nbsp;It was borderline unprofessional the way this was going and I want to apologize now to those involved for being so very unclear in my reasoning and my rhetoric as to stir up a senseless debate about points we essentially agreed on beforehand. &nbsp;As such, I’ve made some revisions to the proposal, I request that you all please re-read it (at <a href="https://github.com/typelift/swift-evolution/blob/either-or/proposals/0024-either.md" class="">https://github.com/typelift/swift-evolution/blob/either-or/proposals/0024-either.md</a>) before we try again so we can refocus this debate on more productive avenues of discourse.</div>
<div class=""><br class=""></div>
<div class="">Throughout this reply I’ve made heavy use of quotes from other replies. &nbsp;Those will appear in purple. &nbsp;Quotes from the proposal will appear in blue.</div>
<div class=""><br class=""></div>
<div class="">The type “Either” that we describe in the proposal is a placeholder. &nbsp;I feel that must be emphasized, because there have been arguments about the name. &nbsp;We specifically mention this in the proposal:</div>
<div class=""><br class=""></div>
<div class=""></div>
<blockquote type="cite" class="">
<div class=""><font color="#0061FF" class=""><span style="font-family: 'Helvetica Neue', Helvetica, 'Segoe UI', Arial, freesans, sans-serif, 'Apple Color Emoji', 'Segoe UI Emoji', 'Segoe UI Symbol'; background-color: rgb(255, 255, 255);" class="">The Swift Standard Library will be updated to include a left-biased sum type we have called&nbsp;</span><code style="box-sizing: border-box; font-family: Consolas, 'Liberation Mono', Menlo, Courier, monospace; padding: 0.2em 0px; margin: 0px; background-color: rgba(0, 0, 0, 0.0392157); border-top-left-radius: 3px; border-top-right-radius: 3px; border-bottom-right-radius: 3px; border-bottom-left-radius: 3px;" class="">Either</code><span style="font-family: 'Helvetica Neue', Helvetica, 'Segoe UI', Arial, freesans, sans-serif, 'Apple Color Emoji', 'Segoe UI Emoji', 'Segoe UI Symbol'; background-color: rgb(255, 255, 255);" class="">&nbsp;- though other names may be appropriate depending on how the type is implemented.</span></font></div>
</blockquote>
<div class=""><br class=""></div>
What we are requesting is a finite-case, here precisely two-case, type that represents two disjoint possibilities. &nbsp;As noted before, this type is often called Result by Swift framework authors and notably the programming language Rust which uses it in place of an exception handling mechanism.<br class="">
<div class=""><br class=""></div>
<div class="">
<blockquote type="cite" class="">Your motivating examples (including all the projects you linked except "Any many more") overwhelmingly use the Either (or similar type) to represent success/failure. I'm not sure there's a single example where the names Left and Right actually make sense in the problem domain.</blockquote>
<br class=""></div>
<div class="">
<blockquote type="cite" class="">There absolutely is a cost. `Result&lt;T&gt;` has a rather intuitive meaning. `Either&lt;T&gt;` has&nbsp;<i class="">no intuitive meaning whatsoever</i>. It says absolutely&nbsp;<i class="">nothing</i>&nbsp;about what it means beyond the fact that there are two potential values. As a result, it is a largely useless type whose sole redeeming feature is it allows developers to avoid having to define their own enum, but in most cases that aren't covered by Result&lt;T&gt; you actually&nbsp;<i class="">want</i>&nbsp;to define your own enum so you can attach meaning to the value.</blockquote>
</div>
<div class=""><br class=""></div>
<div class="">
<blockquote type="cite" class="">You've mentioned Rust many times, but I don't understand why. Rust does _not_ have an Either type. In fact, Rust's success is a great example of how Either is unnecessary. What Rust does have is a Result&lt;T,E&gt; type, and the lack of a more generically-named Either type was an intentional decision (with pretty much the same rationale that I've been giving).</blockquote>
</div>
<div class=""><br class=""></div>
<div class="">We recognize that Result conveys a particular semantics that encourage this type to cross over into the error-handling domain. &nbsp;As noted in the proposal, we don’t want to emphasize this case because a version of this proposal was already rejected for overlapping too heavily with throws. &nbsp;If the community feels that the proposal deserves to be rewritten in a way that re-emphasizes this case and makes that point then I am up for it. &nbsp;But, I request that this not be used as an argument to reduce the genericity of the type - which is to say I don’t wish to see a Result&lt;T&gt; or a Result&lt;T, E : ErrorType&gt; because they reduce the power of the original proposal.</div>
<div class=""><br class=""></div>
<div class="">When I use the term genericity, I am not arguing for the naming scheme of the Either we have, I’m arguing for the structure to be kept around as-is. &nbsp;My biggest fear is that a Result with one lobe and an Error is going to be merged rather than the full proposal because this type and the discussion of it outside of here can become too absorbed in the error-handling case. &nbsp;I do not wish to lose the structure of the type we have now, because that structure is precisely what a future Swift could generalize and abstract upon. &nbsp;The name, however, is up for grabs. &nbsp;We offer a list of alternatives at the end of the proposal, if you have any more to suggest please reply to me here and I’ll see about adding them.</div>
<div class=""><br class=""></div>
<div class="">At the same time, it has been brought up that Either conveys no immediate useful information. &nbsp;At the time of writing this proposal, we do not believe that to be the case, but we recognize that by naming this Result we can reach a wider audience. &nbsp;At the end of the day the proposal is about merging in a 2-case sum type. &nbsp;We chose Either not because we wanted to see it merged, but precisely <i class="">because it was so meaning-agnostic</i>. &nbsp;It’s our lorem-ipsum. &nbsp;For those that think we’re trying to merge a Haskell-ism, I can say with complete confidence that no part of TypeLift intended that in the original proposal. &nbsp;Whatever bad taste Haskell may have left in anybody’s mouth, the Either in our proposal is a placeholder for a name to be decided upon by the community. &nbsp;I felt that this was clear from the line&nbsp;</div>
<div class=""><br class=""></div>
<div class="">
<div class=""></div>
</div>
<blockquote type="cite" class="">
<div class=""><font color="#3A88FE" class="">though other names may be appropriate depending on how the type is implemented.</font></div>
</blockquote>
<div class=""><br class=""></div>
<div class="">and</div>
<div class=""><br class=""></div>
<div class="">
<div class=""></div>
<blockquote type="cite" class="">
<div class=""><font color="#0061FF" class="">In addition, the name `Either` does not lend much to the imagination,</font></div>
<div class=""><font color="#0061FF" class="">and the use of `Left` and `Right` have the potential to cause confusion to</font></div>
<div class=""><font color="#0061FF" class="">novices expecting a `Result&lt;T&gt;`</font></div>
</blockquote>
</div>
<div class=""><br class=""></div>
in the original proposal, but I was wrong. &nbsp;I have updated the draft accordingly.
<div class=""><br class=""></div>
<div class="">
<div class="">
<div class="">Besides, even if the type in the proposal were to be merged right this very second, “meaningless" names and all, a domain-specific Result type could easily be recovered from it. &nbsp;The same is not true of a type that is immediately domain-specific like the reduced-generic forms of Result. &nbsp;To translate that into the language of Result using Either as a template: If a Result&lt;T, E&gt; were not merged, then it could not be recovered from Result&lt;T&gt; in any meaningful manner. &nbsp;However, a constrained Result&lt;T, E : ErrorType&gt; <i class="">can</i> be recovered from the fully generic type in the proposal.</div>
<div class=""><br class=""></div>
<div class="">
<blockquote type="cite" class=""><span style="background-color: rgba(255, 255, 255, 0);" class=""><font color="#874EFE" class="">I agree with Kevin and others that we’re likely to be destined to introduce a real Result type. &nbsp;This will serve the most common cases that you’re citing as use cases for a fully generic Either type, and provide good names. &nbsp;Why should we add a type to the standard library that has very few remaining use cases, and leads to a code style that we don’t want?</font></span></blockquote>
<br class=""></div>
<div class="">This is in line with the goals of the proposal and I would certainly support this renaming if it serves the community’s best interest. &nbsp;You all are, by now, aware of my qualms with the name, but I’m not one to dwell on these things when we’ve made it clear in the proposal that the type can go by many names. &nbsp;It’s the structure of a sum that we’re after, and we’re willing to take it how it comes - but contingent on the shape of the type not differing from the proposal as written. &nbsp;I request that if the name Result be brought up again, that it come with the specific number and kind of parameters involved so we can nail down the shape being discussed.</div>
<div class=""><br class=""></div>
<div class="">
<blockquote type="cite" class="">The argument is often made that we should have a generic “Either” type (though the name doesn’t matter, I’m talking about the semantics you’re describing) to complement tuples. &nbsp;However, the Either type you are providing is not analogous to Swift tuples, because Swift tuples allow you to *name* the elements of the tuple, and is generic w.r.t. the number of elements. &nbsp;Your Either type has neither of these features.</blockquote>
</div>
<div class=""><br class=""></div>
<div class="">Contrary to the impression the other discussion has made, nowhere in the proposal do we wish to augment the type system. &nbsp;If this is done correctly, the type in the proposal should be a ~40-line addition to the standard library, it should not wind up as a full-blown language change. &nbsp;We are not advocating for an n-element sum type, nor are we arguing for a structural typing scheme that would put variadic sums in the language because we recognize that solution is untenable. &nbsp;We are, however, advocating for the inclusion of a 2-case sum type we happen to call Either in writing.</div>
<div class=""><br class=""></div>
<div class=""></div>
<blockquote type="cite" class="">
<div class="">The type system already supports N-ary “either” types. &nbsp;We call them enums.</div>
<br class=""></blockquote>
<div class=""><br class=""></div>
<div class="">
<blockquote type="cite" class="">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.</blockquote>
</div>
<div class=""><br class=""></div>
<div class="">Because this is a non-goal of the type. The sum as presented in the proposal does not attempt to take the place of enums, nor does it make any bones about being a finite entity. &nbsp;We are specifically emphasizing the two-element case. &nbsp;Any other arguments that pertain to its inclusion as a feature of the type system should start at the last site of discussion and probably terminate in a separate proposal adding that kind of scheme to the Swift language itself. &nbsp;We are arguing for a simple change to the standard library, nothing more.</div>
<div class=""><br class=""></div>
<div class="">
<div class=""></div>
<blockquote type="cite" class="">
<div class=""><font color="#3A88FE" class="">As before, unlike `throws`, a disjoint union type can be applied in arbitrary</font></div>
<div class=""><font color="#3A88FE" class="">positions, used as a member, and easily checked for completeness</font></div>
<div class=""><font color="#3A88FE" class="">at compile time. &nbsp;In addition, the lack of a standard union type has</font></div>
<div class=""><font color="#3A88FE" class="">led the Swift community to create [numerous](<a href="https://github.com/search?utf8=%E2%9C%93&amp;q=Either+language%3Aswift" class="">https://github.com/search?utf8=✓&amp;q=Either+language%3Aswift</a>) duplicate implementations of the</font></div>
<div class=""><font color="#3A88FE" class="">same mutually incompatible types over and over and over again. &nbsp;In the</font></div>
<div class=""><font color="#3A88FE" class="">interest of promoting a type that there has received clear interest by the</font></div>
<div class=""><font color="#3A88FE" class="">community, the addition to the Standard Library is necessary.</font></div>
</blockquote>
</div>
<div class=""><br class=""></div>
<div class="">The argument is not “let’s toss out all implementations of 2-case enums in favor of this sum” it’s “very often, when you’ve got a two-case enum with bias, you’ve got a sum described in the proposal”. &nbsp;This pattern shows up in a sufficiently large number of cases that we feel that the standard library deserves to have the final say as to a community-guided implementation of this type because individual implementations seem to differ only in a few minor places like naming or generic positions.</div>
<div class=""><br class=""></div>
<div class="">
<blockquote type="cite" class="">I perceive a common Result/Either type as being desired for composability. If I have two libraries that define their own Result/Either/etc. types, my ability to compose functions across those libraries is impacted.&nbsp;</blockquote>
</div>
<div class=""><br class=""></div>
<div class="">This is another motivating factor that lines up with a major tenant of the proposal. &nbsp;We would not be suggesting this change to the standard library if we did not see this pattern show up in a number of large frameworks, applications, and everything in between. &nbsp;We offer a section of motivating examples and links that should convince you of its commonality if that is still a sticking point.</div>
<div class=""><br class=""></div>
<div class="">
<blockquote type="cite" class="">I’d say “works”, not works; the ergonomics are terrible, you are unlikely to be able to take advantage of the bias anymore, and even if we overlook all that, you still have to enforce an external convention to get mutual-interoperability at each n; otherwise, you may say Either&lt;Either&lt;,&gt;,Either&lt;,&gt;&gt; but I may say Either&lt;Either&lt;Either&lt;,&gt;,&gt;,&gt; and someone else may say Either&lt;,Either&lt;,Either&lt;,&gt;&gt;&gt; and someone else says Either&lt;,Either&lt;Either&lt;,&gt;,&gt;&gt; and so on…</blockquote>
</div>
<div class=""><br class=""></div>
<div class="">This point, while valid, is also an unfortunate feature of Optionals as well, which I have argued can be viewed as an Sum with one lobe “sealed” by Top, the empty tuple. &nbsp;I have yet to see a use of a sum type that needs nesting like this, nor have I seen any type or type alias that attempts to use this to recover an n-ary Sum because it just doesn’t happen. &nbsp;If you have a disjoint set of possibilities with order greater than two, as Chris noted, Swift already offers enums. &nbsp;And if such a case has arisen, it needs to be refactored just as Optional&lt;Optional&lt;Optional&lt;...&gt;&gt;&gt; would be.</div>
<div class=""><br class=""></div>
<div class=""></div>
<blockquote type="cite" class="">
<div class="">&nbsp;* An either-like type should be named something meaningful for the context it is used</div>
</blockquote>
<div class=""><br class=""></div>
<div class="">See above.</div>
<br class="">
<blockquote type="cite" class="">
<div class="">&nbsp;* There are a lot of cases where an either-like type is useful, there may generalised functions that are often used on them</div>
</blockquote>
<div class=""><br class=""></div>
<div class="">See proposal.</div>
<br class="">
<blockquote type="cite" class="">
<div class="">&nbsp;* Is defining or re-defining an either type hard?</div>
</blockquote>
<div class=""><br class=""></div>
See proposal.
<div class=""><br class="">
<blockquote type="cite" class="">
<div class="">&nbsp;* Is it too niche to be in the standard library</div>
</blockquote>
<div class=""><br class=""></div>
We don’t believe so, see proposal.</div>
<div class=""><br class=""></div>
<div class="">
<blockquote type="cite" class="">No, I take issue with the entire fundamental idea behind your proposal. You've explicitly defined this type purely by its shape, with no meaning whatsoever given to either variant, except insofar as the type is Left-biased (which only serves to be even more confusing; since there's no actual meaning assigned to Left/Right, what is the justification for adding the left-biasing?)<br class=""></blockquote>
<div class=""><br class=""></div>
<div class="">The rationale given for bias has been updated in the latest draft.</div>
<div class=""><br class=""></div>
<div class="">tl;dr</div>
<div class=""><br class=""></div>
<div class="">
<blockquote type="cite" class=""><span style="background-color: rgba(255, 255, 255, 0);" class=""><font color="#5E30EB" class="">I agree with Kevin and others that we’re likely to be destined to introduce a real Result type. &nbsp;This will serve the most common cases that you’re citing as use cases for a fully generic Either type, and provide good names.&nbsp;</font></span></blockquote>
</div>
<div class=""><br class=""></div>
<div class="">
<blockquote type="cite" class="">
<div class="">On Jan 20, 2016, at 10:17 PM, Developer &lt;<a href="mailto:devteam.codafi@gmail.com" class="">devteam.codafi@gmail.com</a>&gt; wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div class="">Hey all,<br class="">
<br class="">
Just added a section of motivating examples to the Either proposal. &nbsp;Ping me if you have any more that I missed ('cause I'm sure I did miss a lot).<br class="">
<br class="">
<a href="https://github.com/typelift/swift-evolution/blob/either-or/proposals/0024-either.md#motivating-examples" class="">https://github.com/typelift/swift-evolution/blob/either-or/proposals/0024-either.md#motivating-examples</a><br class="">
<br class="">
~Robert Widmann<br class="">
<br class="">
2016/01/09 14:19、Developer &lt;<a href="mailto:devteam.codafi@gmail.com" class="">devteam.codafi@gmail.com</a>&gt; のメッセージ:<br class="">
<br class="">
<blockquote type="cite" class="">Because the last discussion, while substantive and very much appreciated, did not debate the proposal much, I'd like to begin discussion anew about the addition of an Either type to the Swift Standard Library. &nbsp;The proposal can be found here (<a href="https://github.com/apple/swift-evolution/pull/67#issuecomment-170269481" class="">https://github.com/apple/swift-evolution/pull/67#issuecomment-170269481</a>) and a link to the root our previous round of discussion is here (<a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/001394.html" class="">https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/001394.html</a>).<br class="">
<br class="">
Thanks all!<br class="">
<br class="">
~Robert Widmann<br class=""></blockquote>
</div>
</div>
</blockquote>
</div>
<br class=""></div>
</div>
</div>
</div>
_______________________________________________<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" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div>
</blockquote>
</div>
<br class=""></div>
_______________________________________________<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" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></blockquote>
</div>
</div>
_______________________________________________<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" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div>
</blockquote>
</div>
<br class=""></div>
</blockquote>
</div>
</div>

_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></div></body></html>