<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&#39;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&#39;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&#39;t come up with other names that are particularly meaningful), which I&#39;d suggest is pretty rare (nothing immediately comes to mind that is really this generic), by using the stdlib-provided Either type you&#39;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&#39;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&#39;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&#39;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&#39;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&#39;ve seen in Haskell that wasn&#39;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&#39;s been no push to add an Either type to the stdlib (I don&#39;t think I&#39;ve even seen it so much as suggested ever since Result was added, although I haven&#39;t been paying as much attention to Rust since 1.0 came out so I can&#39;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">&lt;<a href="mailto:kevin@sb.org" target="_blank">kevin@sb.org</a>&gt;</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&#39;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&#39;m wondering why I apparently shouldn&#39;t have wished that, but been glad that I&#39;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&#39;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&#39;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&#39;t come up with other names that are particularly meaningful), which I&#39;d suggest is pretty rare (nothing immediately comes to mind that is really this generic), by using the stdlib-provided Either type you&#39;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&#39;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&#39;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&#39;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&#39;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&#39;ve seen in Haskell that wasn&#39;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&#39;s been no push to add an Either type to the stdlib (I don&#39;t think I&#39;ve even seen it so much as suggested ever since Result was added, although I haven&#39;t been paying as much attention to Rust since 1.0 came out so I can&#39;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>