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?
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:
Issues · non/cats · GitHub).
On Dec 9, 2015, at 6:44 PM, Ilias Karim <ilias.karim@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@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@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@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@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@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@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution