<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><pre style="white-space: pre-wrap; background-color: rgb(255, 255, 255);" class=""></pre><blockquote type="cite" class=""><pre style="white-space: pre-wrap; background-color: rgb(255, 255, 255);" class="">I do not support the addition of Either. As far as I am aware, the only
compelling argument in favor of an Either type is "because Haskell has
one", but I believe it's commonly recognized that Haskell's Either is
not particularly good. </pre></blockquote><div class="">I have yet to read counterarguments about the addition of Either to the Haskell base library. And though it may be tempting to assume, because TypeLift is oriented towards declarative programming, that we wish to see Swift and Haskell enter some kind of unholy union (excuse the pun), I based this proposal not off of a desire to see more FP, but to see less duplicate implementations (<a href="https://github.com/search?utf8=✓&q=Either+language%3Aswift&type=Code&ref=searchresults" class="">https://github.com/search?utf8=✓&q=Either+language%3Aswift&type=Code&ref=searchresults</a>). If GitHub is any indicator, the Swift community wants an Either, and it seems fitting to me that the language standardize on one and allow the community to instead focus their efforts on writing interesting extensions to such a common type. </div><div class=""><br class=""></div><div class="">If you need a less anecdotal argument, consider the type of program `throws` can represent versus the type of program `Either` can represent. On the one hand, yes, the latter does have certain conventions that encourage it to duplicate cases that the former already provides, but Either is supposed to properly represent a computation that can produce multiple discrete results - an if-else as a value. If you wish to support more arities, nest down the left or right lobe of the type as you would nest branches. If you want to start supporting higher-order variants, you start to run into inclusion-exclusion problems (see how we implemented a `Those` type <a href="https://github.com/typelift/Swiftz/blob/master/Swiftz/Those.swift" class="">https://github.com/typelift/Swiftz/blob/master/Swiftz/Those.swift</a>) </div><blockquote type="cite" class=""><pre style="white-space: pre-wrap; background-color: rgb(255, 255, 255);" class="">It's a weird name for results (which Result
covers), and for other cases it's usually better just to define your own
two-variant enum anyway. Rust provides some evidence in favor of this,
as this was the rationale for why Rust has a Result<T,E> but no Either,
and it turns out there has been no need to add an Either.</pre></blockquote><div class="">I’ll admit, the name is definitely less than ideal, but it should be a simple thing to change (I’m only interested in the structure here): XOr, Choice, Variant, Alternative, V come to mind.</div></body></html>