[swift-evolution] [proposal] Either in the Swift Standard Library

Kevin Ballard kevin at sb.org
Tue Jan 26 01:30:09 CST 2016

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?)

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.

Also, FWIW, every single one of your motivating examples would be significantly improved by the use of a Result<T>or Result<T,E>instead of Either.

-Kevin Ballard

On Jan 25, 2016, 11:21 PM -0800, Developer<devteam.codafi at gmail.com>, wrote:
> So you take issue with the name?Have you seen our section of alternatives?
> ~Robert Widmann
> 2016/01/26 1:39、Kevin Ballard<kevin at sb.org(mailto:kevin at sb.org)>のメッセージ:
> > Then we are fundamentally at odds, because I am categorically opposed to any solution that doesnothave 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<T>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.
> >  
> > -Kevin Ballard
> > > On Jan 25, 2016, at 10:27 PM, Developer<devteam.codafi at gmail.com(mailto:devteam.codafi at gmail.com)>wrote:
> > > Are you opposed to the name or the semantics?
> > >  
> > > I will not accept a revision that reduces the level of abstraction of the current proposal.I will, however, accept name changes.Result, though, I believe is out of the question.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.I do not wish to emphasize the error case, or the theoretical case, I wish to encourage the general case.We must remember that despite Rust's success, they do not have to live alongside an exceptions mechanism like Either does.
> > >  
> > > ~Robert Widmann
> > >  
> > > 2016/01/26 0:55、Kevin Ballard via swift-evolution<swift-evolution at swift.org(mailto:swift-evolution at swift.org)>のメッセージ:
> > >  
> > > > There absolutely is a cost. `Result<T>` has a rather intuitive meaning. `Either<T>` hasno intuitive meaning whatsoever. It says absolutelynothingabout 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<T>you actuallywantto define your own enum so you can attach meaning to the value.
> > > > If it's not obvious, I'm very strongly against having a generic Either type, but I do want a Result<T>or Result<T,E>.
> > > > -Kevin Ballard
> > > >  
> > > > On Fri, Jan 22, 2016, at 10:22 PM, Developer via swift-evolution wrote:
> > > > > My overwhelming concern, after having a conversation with Chris, is that implementing a Result<T>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.In F#, Core.Choice can be used to build a Validation or Result monad, but the converse is impossible.
> > > > > ~Robert Widmann
> > > > > 2016/01/23 1:05、Rob Mayoff via swift-evolution<swift-evolution at swift.org(mailto:swift-evolution at swift.org)>のメッセージ:
> > > > > > > Just added a section of motivating examples to the Either proposal.Ping me if you have any more that I missed ('cause I'm sure I did miss a lot).
> > > > > > > https://github.com/typelift/swift-evolution/blob/either-or/proposals/0024-either.md#motivating-examples
> > > > > > 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.
> > > > > > 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.)
> > > > > > I think a Result/Success/Failure type is warranted, but I'm very skeptical about generic Either/Left/Right.
> > > > > > _______________________________________________
> > > > > > swift-evolution mailing list
> > > > > > swift-evolution at swift.org(mailto:swift-evolution at swift.org)
> > > > > > https://lists.swift.org/mailman/listinfo/swift-evolution
> > > > > _______________________________________________
> > > > > swift-evolution mailing list
> > > > > swift-evolution at swift.org(mailto:swift-evolution at swift.org)
> > > > > https://lists.swift.org/mailman/listinfo/swift-evolution
> > > > _______________________________________________
> > > > swift-evolution mailing list
> > > > swift-evolution at swift.org(mailto:swift-evolution at swift.org)
> > > > https://lists.swift.org/mailman/listinfo/swift-evolution
> >  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160125/3cd3c186/attachment.html>

More information about the swift-evolution mailing list