Proposal: An Either Type in the STL

Evolution Discussion
1

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.

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 (Sign in to GitHub · GitHub). 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.

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 https://github.com/typelift/Swiftz/blob/master/Swiftz/Those.swift\)

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.

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.

2

Can you provide any examples where you think it's demonstrably better to
have an Either than to just implement your own two-variant type,
assuming that we do already have a Result type to handle results?

I haven't gone trawling through GitHub for Either, but glancing through
that search you provided, it looks like it's basically just people
trying to reproduce Haskell concepts in Swift, which isn't particularly
meaningful. The only non-FP justification I saw was robrix/Either which
demonstrated using an Either to hold the results of a computation, which
of course is what Result does, and really the only reason it's called
Either is because of FP anyway.

-Kevin Ballard

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.

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
(Sign in to GitHub · GitHub)
. 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.

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
https://github.com/typelift/Swiftz/blob/master/Swiftz/Those.swift\)

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.

···

On Fri, Dec 11, 2015, at 08:09 PM, Developer via swift-evolution wrote:

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.

_________________________________________________
swift-evolution mailing list swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

3

Can you provide any examples where you think it's demonstrably better to
have an Either than to just implement your own two-variant type, assuming
that we do already have a Result type to handle results?

Any time there are specifically two discrete choices or states. Yes, "if
you have three then you should make a custom enum" but–if you only have
two–the benefit of using Either *instead* of a custom enum is that you can
leverage all of the same machinery without much extra effort. You can reply
to every possible example with "you could make a custom enum with two
cases" but, for every one of those, you would get nothing for free. If
Either makes it into the standard library and you *don't* want that
machinery, you can create your own custom enum.

As for a concrete example, Scales are, typically symmetrical (ascending and
descending) or asymmetrical. Ideally, I would like to wrap Either in a
newtype and call it a day. .Left is not an error case so the argument about
that being counterintuitive is moot. I simply have two possibilities to
choose from and I am fairly certain that that will not change in the future.

···

On Sat, Dec 12, 2015 at 7:43 AM, Kevin Ballard via swift-evolution < swift-evolution@swift.org> wrote:

I haven't gone trawling through GitHub for Either, but glancing through
that search you provided, it looks like it's basically just people trying
to reproduce Haskell concepts in Swift, which isn't particularly
meaningful. The only non-FP justification I saw was robrix/Either which
demonstrated using an Either to hold the results of a computation, which of
course is what Result does, and really the only reason it's called Either
is because of FP anyway.

-Kevin Ballard

On Fri, Dec 11, 2015, at 08:09 PM, Developer via swift-evolution wrote:

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.

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 (
Sign in to GitHub · GitHub).
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.

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
https://github.com/typelift/Swiftz/blob/master/Swiftz/Those.swift\)

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.

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.

*_______________________________________________*
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution