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

[T.J. Usiyan]

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