[swift-evolution] Proposal: An Either Type in the STL
Kevin Ballard
kevin at sb.org
Thu Dec 10 13:25:44 CST 2015
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/fe23b3fc/attachment.html>
More information about the swift-evolution
mailing list