<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=""><blockquote type="cite" class=""><div dir="auto" class=""><div class="">I believe we disagree at such a level, outside of naming and what all that entails, because this seems like a Haskellism and Haskell's idea about error handling is opinionated to some and is made even more so by an implicit understanding required to interact with the rest of the ecosystem. &nbsp;Either is not a fundamentally meaningless type in Haskell, or here, and it has a very precise interpretation computationally. &nbsp;Trouble is, conveying that sentiment also inevitably leads to incredibly technical arguments that leaves novices with a bitter taste - who wants to learn about Profunctors to figure out why Either had a right-bias anyhow? &nbsp;The proposal is aimed towards the Swift community, not the Haskell one. &nbsp;</div></div></blockquote><div class=""><br class=""></div><div class="">Since this is more of a fundamental / glue type for functional paradigm — a common type between potential functional oriented libraries (you don’t want to have two libraries, then convert between the two — you want them to play together). &nbsp; Without fleshing out the common usage within different functional implementations it may be a hard sell… (i.e. review in combination with other proposals). &nbsp;</div><div class=""><br class=""></div><div class="">As for the earlier comment about Scala having Try, Scala also has Either - Either being implemented first then Try implemented as a wrapper for Try/Throw/Catch functionality (maybe something about try/catch are within one jvm thread which gets lost when you are implementing actors etc. which are across servers - so wrapping a java exception with a monadic type). &nbsp;Swift already has try’s. &nbsp;</div><div class=""><br class=""></div><div class="">PS if I am not coherent - it is because I am under the influence :o</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">&nbsp;&nbsp;</div><br class=""><div><blockquote type="cite" class=""><div class="">On 2016-01-26, at 14:59:54, 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="">Because the shape is what matters to me most. &nbsp;Whether the type is defined as&nbsp;</div><div class=""><br class=""></div><div class="">enum Either&lt;L, R&gt; { //... }<br class=""><span style="background-color: rgba(255, 255, 255, 0);" class="">enum Result&lt;T, E&gt; { //... }</span></div><div class=""><span style="background-color: rgba(255, 255, 255, 0);" class="">enum Choice&lt;This, That&gt; { //... }</span></div><div class=""><span style="background-color: rgba(255, 255, 255, 0);" class="">enum XOR&lt;L, R&gt; { //... }</span></div><div class=""><span style="background-color: rgba(255, 255, 255, 0);" class="">enum V&lt;L, R&gt; { //... }</span></div><div class=""><span style="background-color: rgba(255, 255, 255, 0);" class="">enum These&lt;L, R&gt; { //... }</span></div><div class=""><br class=""></div><div class="">the point is that the standard library offers a sum type that doesn't attempt to invade the space taken over by throws (as I say in the proposal). &nbsp;If we are to encourage that, then a type named Result that has a lobe specifically dedicated to error handling, in some cases even constrained by ErrorType, is an invasion indeed. &nbsp; The type needn't carry semantics already provided by the language, and in that case it must carry the most general of semantics: those implied by structure and reinforced by documentation.</div><div class=""><br class=""></div><div class="">As for bias, I'll admit that it is insufficiently addressed in the proposal (however I do acknowledge this very question would arise). &nbsp;We chose a left bias because of Rust's success and a lack of Haskell-style biased type application to deal with in type classes (not that we have any now anyway). &nbsp;From a less technical perspective, the idea that an error should come first is counterintuitive. &nbsp;It makes more sense to emphasize the successful case by placing it "first".</div><div class=""><br class=""></div><div class="">I believe we disagree at such a level, outside of naming and what all that entails, because this seems like a Haskellism and Haskell's idea about error handling is opinionated to some and is made even more so by an implicit understanding required to interact with the rest of the ecosystem. &nbsp;Either is not a fundamentally meaningless type in Haskell, or here, and it has a very precise interpretation computationally. &nbsp;Trouble is, conveying that sentiment also inevitably leads to incredibly technical arguments that leaves novices with a bitter taste - who wants to learn about Profunctors to figure out why Either had a right-bias anyhow? &nbsp;The proposal is aimed towards the Swift community, not the Haskell one. &nbsp;</div><div class=""><br class=""></div><div class="">I request that you suspend any preconceptions and take this for what it is: A sum type, nothing more. &nbsp;If we wished to cause damage to the community, this proposal would be about replacing throws entirely and forcing this change - or even a Result&lt;T&gt; variant of it - upon everybody. &nbsp;In the short term this will make a few more people sit up and think about when they need throws and when they need a sum. &nbsp;In the long term it will enable a new class of typesafe programs and higher-order patterns to be written without dependence on a third party.</div><div class=""><br class=""></div><div class="">So, that said, I'm open to a name change, but we must keep the generality of the type intact to a point.</div><div class=""><br class=""><div class="">~Robert Widmann</div></div><div class=""><br class="">2016/01/26 2:30、Kevin Ballard &lt;<a href="mailto:kevin@sb.org" class="">kevin@sb.org</a>&gt; のメッセージ:<br class=""><br class=""></div><blockquote type="cite" class=""><div class="">

<title class=""></title>


<div name="messageBodySection" 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="">
<br class="">
A type like this in the standard library will have a significant detrimental effect on the entire Swift ecosystem. Swift makes it so easy to define types with semantic meaning, but this type is only useful if people actually use it, and every time someone uses this they'll be losing the semantic meaning that would have been carried by the type they'd have defined otherwise.<br class="">
<br class="">
Also, FWIW, every single one of your motivating examples would be significantly improved by the use of a Result&lt;T&gt; or Result&lt;T,E&gt; instead of Either.</div>
<div name="messageSignatureSection" class=""><br class="">
-Kevin Ballard</div>
<div name="messageReplySection" class=""><br class="">
On Jan 25, 2016, 11:21 PM -0800, Developer &lt;<a href="mailto:devteam.codafi@gmail.com" class="">devteam.codafi@gmail.com</a>&gt;, wrote:<br class="">
<blockquote type="cite" class="">
<div class="">So you take issue with the name? &nbsp;Have you seen our section of alternatives?</div>
<div class=""><br class="">
~Robert Widmann</div>
<div class=""><br class="">
2016/01/26 1:39、Kevin Ballard &lt;<a href="mailto:kevin@sb.org" class="">kevin@sb.org</a>&gt; のメッセージ:<br class="">
<br class=""></div>
<blockquote type="cite" class="">
<div class="">
<meta http-equiv="Content-Type" content="text/html charset=utf-8" class="">
<div class="">Then we are fundamentally at odds, because I am categorically opposed to any solution that does <i class="">not</i>&nbsp;have specific meaning attached to the two variants. Either is an awful type that only serves to make APIs harder to understand, and literally every non-trivial usage of Either I’ve actually seen in practice, it has been used exactly the way Result&lt;T&gt; would naturally be defined (where “trivial” means usage in any kind of actual API, as opposed to sample code or scratch functions using Either to prototype something that, if turned into actual API, would replace the usage of Either with a more well-defined enum). And the existence of Either only serves to encourage people to use it, which produces an overall negative effect on the quality of APIs.</div>
<div class=""><br class=""></div>
<div class="">-Kevin Ballard</div>
<br class="">
<div class="">
<blockquote type="cite" class="">
<div class="">On Jan 25, 2016, at 10:27 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="">
<meta http-equiv="content-type" content="text/html; charset=utf-8" class="">
<div dir="auto" class="">
<div class="">Are you opposed to the name or the semantics?</div>
<div class=""><br class=""></div>
<div class="">I will not accept a revision that reduces the level of abstraction of the current proposal. &nbsp;I will, however, accept name changes. &nbsp;Result, though, I believe is out of the question. &nbsp;It strongly implies a common but pointed set of semantics that discourage thinking of this type as data and more as an alternative to throws. &nbsp;I do not wish to emphasize the error case, or the theoretical case, I wish to encourage the general case. &nbsp;We must remember that despite Rust's success, they do not have to live alongside an exceptions mechanism like Either does.<br class="">
<br class="">
<div class="">~Robert Widmann</div>
</div>
<div class=""><br class="">
2016/01/26 0:55、Kevin Ballard via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; のメッセージ:<br class="">
<br class=""></div>
<blockquote type="cite" class="">
<div class="">
<div 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> 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> to define your own enum so you can attach meaning to the value.<br class=""></div>
<div class="">&nbsp;</div>
<div class="">If it's not obvious, I'm very strongly against having a generic Either type, but I do want a Result&lt;T&gt; or Result&lt;T,E&gt;.<br class=""></div>
<div class="">&nbsp;</div>
<div class="">-Kevin Ballard</div>
<div class="">&nbsp;</div>
<div class="">On Fri, Jan 22, 2016, at 10:22 PM, Developer via swift-evolution wrote:<br class=""></div>
<blockquote type="cite" class="">
<div class="">
<div class="">My overwhelming concern, after having a conversation with Chris, is that implementing a Result&lt;T&gt; means we are strongly implying a particular semantics and use case when we could generalize and abstract for no cost but an extra generic parameter. &nbsp;In F#, Core.Choice can be used to build a Validation or Result monad, but the converse is impossible.<br class=""></div>
<div class="">&nbsp;</div>
<div class="">~Robert Widmann<br class=""></div>
</div>
<div class="">
<div class="">&nbsp;</div>
<div class="">2016/01/23 1:05、Rob Mayoff via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; のメッセージ:<br class=""></div>
</div>
<blockquote type="cite" class="">
<div class="">
<div dir="ltr" class="">
<div class="">
<div class="">
<blockquote style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204, 204, 204);border-left-style:solid;padding-left:1ex;" class="">
<div 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=""></div>
<div class="">&nbsp;</div>
<div 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=""></div>
<div class="">&nbsp;</div>
</blockquote>
<div class="">&nbsp;</div>
<div 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. I'm not 100% sure about func alternate in Madness/Alternation.swift. It definitely uses Left/Right to mean Failure/Result, but I couldn't tell if it also uses them as something else. Which makes those names all the more maddening.<br class=""></div>
<div class="">&nbsp;</div>
<div class="">I checked my company's largest Scala project, which is over 300,000 lines. We use Scala's Try/Success/Failure in dozens of places. We use Either/Left/Right once, in a thrown-together report-generating script, which would probably have been written in awk or perl if it didn't need to read binary log files. (The ability of IntelliJ to reliably find all uses of a class or method is not to be underestimated. Hint hint, team Xcode.)<br class=""></div>
<div class="">&nbsp;</div>
<div class="">I think a Result/Success/Failure type is warranted, but I'm very skeptical about generic Either/Left/Right.<br class=""></div>
<div class="">&nbsp;</div>
</div>
</div>
</div>
</div>
</blockquote>
<blockquote type="cite" class="">
<div class="">
<div class=""><span class="">_______________________________________________</span><br class=""></div>
<div class=""><span class="">swift-evolution mailing list</span><br class=""></div>
<div class=""><span class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a></span><br class=""></div>
<div class=""><span class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br class=""></div>
</div>
</blockquote>
<div class=""><u class="">_______________________________________________</u><br class=""></div>
<div class="">swift-evolution mailing list<br class=""></div>
<div class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""></div>
<div 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 class="">&nbsp;</div>
</div>
</blockquote>
<blockquote type="cite" class="">
<div class=""><span class="">_______________________________________________</span><br class="">
<span class="">swift-evolution mailing list</span><br class="">
<span class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a></span><br class="">
<span class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br class=""></div>
</blockquote>
</div>
</div>
</blockquote>
</div>
<br class=""></div>
</blockquote>
</blockquote>
</div>


</div></blockquote></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=""></body></html>