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

[Jacob Bandes-Storch]

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
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151209/d8223c88/attachment.html>