<div dir="ltr"><blockquote style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex" class="gmail_quote">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.<br> <br>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).<br> <br>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.<br> <br>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).</blockquote><div><br></div><div>Thanks for explaining your reasoning, Kevin. </div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Dec 10, 2015 at 12:25 PM, Kevin Ballard <span dir="ltr"><<a href="mailto:kevin@sb.org" target="_blank">kevin@sb.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><u></u>
<div><span class=""><div>On Thu, Dec 10, 2015, at 10:06 AM, Nick Shelley wrote:<br></div>
<blockquote type="cite"><div dir="ltr"><div>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?<br></div>
<div> </div>
<div><div>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.<br></div>
</div>
</div>
</blockquote><div> </div>
</span><div>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.<br></div>
<div> </div>
<div>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).<br></div>
<div> </div>
<div>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.<br></div>
<div> </div>
<div>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).<span class="HOEnZb"><font color="#888888"><br></font></span></div><span class="HOEnZb"><font color="#888888">
<div> </div>
<div>-Kevin Ballard</div>
</font></span></div>
</blockquote></div><br></div>