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

Thu Dec 10 02:34:27 CST 2015

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