[swift-evolution] Proposal: An Either Type in the STL

Thu Dec 10 12:06:25 CST 2015

Can you explain why you think it's better to just define your own
two-variant enum rather than having a built-in Either type, or point me to
the evidence that Rust found in favor of this approach?

I had to create my own Either type for some code I wrote semi-recently and
wished it was built in, so I'm wondering why I apparently shouldn't have
wished that, but been glad that I'm creating my own.

On Thu, Dec 10, 2015 at 1:34 AM, Kevin Ballard via swift-evolution <
swift-evolution at swift.org> wrote:

> I support the addition of a Result, and I encourage people to look at
> https://doc.rust-lang.org/stable/std/result/index.html for a good example
> of how this can be done well. I'd like a Result<T,E> in Swift that looks
> similar.
>
> I do not support the addition of Either. As far as I am aware, the only
> compelling argument in favor of an Either type is "because Haskell has
> one", but I believe it's commonly recognized that Haskell's Either is not
> particularly good. It's a weird name for results (which Result covers), and
> for other cases it's usually better just to define your own two-variant
> enum anyway. Rust provides some evidence in favor of this, as this was the
> rationale for why Rust has a Result<T,E> but no Either, and it turns out
> there has been no need to add an Either.
>
> -Kevin Ballard
>
> On Wed, Dec 9, 2015, at 04:01 PM, T.J. Usiyan via swift-evolution wrote:
>
> I hope that we can get both Either and Result into the standard lib. A
> great situation might be if Result were some sort of newtype declaration of
> Either.
>
> On Thu, Dec 10, 2015 at 5:25 AM, Developer via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> There is!  That’s what the Bifunctor typeclass is for.  But if you had to
> pick just one of them to implement some Functor constraint - some canonical
> `map` function, would you pick the side that you filled with Errors, or the
> side that you filled with Values?
>
>
>
> On Dec 9, 2015, at 6:52 PM, Jacob Bandes-Storch <jtbandes at gmail.com>
> wrote:
>
> Is there not precedent for having both "mapLeft<T>(f: L -> T) -> Either<T,
> R>" and "mapRight<T>(f: R -> T) -> Either<L, T>" ?
>
> Jacob Bandes-Storch
>
> On Wed, Dec 9, 2015 at 3:49 PM, Developer <devteam.codafi at gmail.com>
> wrote:
>
> How would you write `map` for an unbiased Either.  You have to pick a side!
>
> Our implementation happens to be the one standardized on by Scala,
> Haskell, ML, (and to a limited extent) F#.  For a less arbitrary reason,
> the use of "Right as Correct" is because Either, in all it’s Bifunctor-ial
> ways, has to admit two ways to map “across” itself.  To paraphrase the
> words of a friend "There are lots of things in computer science we can
> leftMap”.  In Haskell, such a thing is represented by the Functor
> typeclass, and due to the way type application works in that language, the
> convention has been to map over the rightmost side.  But this isn’t
> Haskell, so our reasons can get even more theoretical than that (if you
> really want to get into what it looks like when you implement Covariant
> mapping down the left side of a common Bifunctor like Either, Cats has
> already had a thorough discussion on the subject:
> https://github.com/non/cats/issues/189).
>
>
> On Dec 9, 2015, at 6:44 PM, Ilias Karim <ilias.karim at gmail.com> wrote:
>
> I’m sorry, I misunderstood. I guess an enum would be the appropriate
> choice, instead.
>
> As far as left/right goes, the decision to have left or right be the
> “correct” value is entirely arbitrary and should be left up to the
> developer. It should be a convention at best.
>
> Ilias
>
>
> On Dec 9, 2015, at 3:43 PM, Dave DeLong <delong at apple.com> wrote:
>
> With a tuple, you have to do “(left: T?, right: U?)”, whereas with an
> Either you are guaranteed to always have one or other other; never both and
> never neither. That is not guaranteed with the tuple.
>
> Dave
>
>
> On Dec 9, 2015, at 4:41 PM, Ilias Karim via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> What are the advantage over using a tuple? One great feature about tuples
> is being able to name parameters so you can dispel ambiguity.
>
>
>
> On Dec 9, 2015, at 3:35 PM, Jacob Bandes-Storch <jtbandes at gmail.com>
> wrote:
>
> 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<Int,
> String>, not just Either<ErrorType, T>.
>
> While I'm not sure Left & 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 & error cases.
>
> Jacob
>
> On Wed, Dec 9, 2015 at 3:32 PM, Ilias Karim via swift-evolution<
> swift-evolution at swift.org>wrote:
>
> Hi Robert,
>
> I agree with your recommendation of a generic Either type.
>
> 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.
>
> Ilias
>
> > On Dec 9, 2015, at 3:06 PM, Developer via swift-evolution <
> swift-evolution at swift.org> wrote:
> >
> > 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.  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.  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 (https://github.com/typelift/Swiftx/blob/master/Swiftx/Either.swift#L16
> ).
> >
> >
> > ~Robert Widmann (CodaFi)
> > _______________________________________________
> > swift-evolution mailing list
> >swift-evolution at swift.org
> >https://lists.swift.org/mailman/listinfo/swift-evolution
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
> *_______________________________________________*
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
> _______________________________________________
> swift-evolution mailing list
> 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/20151210/b177d417/attachment.html>