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

[Jacob Bandes-Storch]

Sorry, I'm bad at this proofreading thing. The fourth case is (A, B).

Jacob Bandes-Storch

On Wed, Dec 9, 2015 at 3:42 PM, Developer <devteam.codafi at gmail.com> wrote:

> A tuple is a product, we want a sum here.  A tuple says “I know I have 2
> things”, a sum says “I know one or the other of these things is here but
> not both” without the need to unwrap both halves just to check.  Past a
> certain point, you’re writing Either code over and over again without
> realizing it.
>
>
> On Dec 9, 2015, at 6:41 PM, Ilias Karim <ilias.karim at gmail.com> 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
>>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151209/45b80d07/attachment.html>