[swift-evolution] Proposal: An Either Type in the STL
jtbandes at gmail.com
Wed Dec 9 17:43:29 CST 2015
Sorry, I'm bad at this proofreading thing. The fourth case is (A, B).
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>
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution