[swift-evolution] Proposal: An Either Type in the STL
jtbandes at gmail.com
Wed Dec 9 17:52:51 CST 2015
Is there not precedent for having both "mapLeft<T>(f: L -> T) -> Either<T,
R>" and "mapRight<T>(f: R -> T) -> Either<L, T>" ?
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:
> 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.
> 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.
> 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>
> 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.
> 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.
>> > 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 (
>> > ~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
> swift-evolution mailing list
> swift-evolution at swift.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution