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

[Nick Shelley]

>
> The simplest argument is that the name Either (and variants Left and
> Right) are so generic as to be meaningless, and there's no good
> alternatives that are any better. By defining your own enum, you get to
> name the enum and its variants (and document them) in a way that's actually
> meaningful.
>
> If you want to use the Either type in a context that actually is pretty
> generic (such that you can't come up with other names that are particularly
> meaningful), which I'd suggest is pretty rare (nothing immediately comes to
> mind that is really this generic), by using the stdlib-provided Either type
> you're also restricting yourself to only ever having 2 variants. If you
> find a need for a 3rd variant later (for example, if you have a function
> that takes two values and it returns one of them, and you later realize you
> want an overload that takes 3 values), then you can't add it to Either and
> have to create your own enum anyway. By starting off with your own enum you
> make it a lot easier to update code for the 3rd variant (only exhaustive
> switches are forced to change, everything else is source-compatible).
>
> Ultimately, given how trivial it is to define a new enum, there's just no
> real compelling reason to have a stdlib-defined Either. The best argument I
> can come up with in favor of using Either instead of your own enum is that
> the stdlib may have already defined methods like mapLeft() and mapRight()
> on Either, but I don't find that to be a very good reason. In most cases
> those methods are not particularly helpful.
>
> Also, in my personal experience, in what (admittedly small) amount of
> Haskell code I've seen, every single instance of Either was being used for
> error handling, and Result already handles that job. Every other case of a
> two-variant data I've seen in Haskell that wasn't error handling, it was a
> custom data instead of Either. And as I already stated, Rust made the
> decision here to have Result and nothing else, and there's been no push to
> add an Either type to the stdlib (I don't think I've even seen it so much
> as suggested ever since Result was added, although I haven't been paying as
> much attention to Rust since 1.0 came out so I can't say that definitively).


Thanks for explaining your reasoning, Kevin.

On Thu, Dec 10, 2015 at 12:25 PM, Kevin Ballard <kevin at sb.org> wrote:

> On Thu, Dec 10, 2015, at 10:06 AM, Nick Shelley wrote:
>
> Can you explain why you think it's better to just define your own
> two-variant enum rather than having a built-in Either type, or point me to
> the evidence that Rust found in favor of this approach?
>
> I had to create my own Either type for some code I wrote semi-recently and
> wished it was built in, so I'm wondering why I apparently shouldn't have
> wished that, but been glad that I'm creating my own.
>
>
> The simplest argument is that the name Either (and variants Left and
> Right) are so generic as to be meaningless, and there's no good
> alternatives that are any better. By defining your own enum, you get to
> name the enum and its variants (and document them) in a way that's actually
> meaningful.
>
> If you want to use the Either type in a context that actually is pretty
> generic (such that you can't come up with other names that are particularly
> meaningful), which I'd suggest is pretty rare (nothing immediately comes to
> mind that is really this generic), by using the stdlib-provided Either type
> you're also restricting yourself to only ever having 2 variants. If you
> find a need for a 3rd variant later (for example, if you have a function
> that takes two values and it returns one of them, and you later realize you
> want an overload that takes 3 values), then you can't add it to Either and
> have to create your own enum anyway. By starting off with your own enum you
> make it a lot easier to update code for the 3rd variant (only exhaustive
> switches are forced to change, everything else is source-compatible).
>
> Ultimately, given how trivial it is to define a new enum, there's just no
> real compelling reason to have a stdlib-defined Either. The best argument I
> can come up with in favor of using Either instead of your own enum is that
> the stdlib may have already defined methods like mapLeft() and mapRight()
> on Either, but I don't find that to be a very good reason. In most cases
> those methods are not particularly helpful.
>
> Also, in my personal experience, in what (admittedly small) amount of
> Haskell code I've seen, every single instance of Either was being used for
> error handling, and Result already handles that job. Every other case of a
> two-variant data I've seen in Haskell that wasn't error handling, it was a
> custom data instead of Either. And as I already stated, Rust made the
> decision here to have Result and nothing else, and there's been no push to
> add an Either type to the stdlib (I don't think I've even seen it so much
> as suggested ever since Result was added, although I haven't been paying as
> much attention to Rust since 1.0 came out so I can't say that definitively).
>
> -Kevin Ballard
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151210/86a91b66/attachment.html>