[swift-evolution] Proposal: An Either Type in the STL

[T.J. Usiyan]

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

> 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.



>
> 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 (
> https://github.com/search?utf8=✓&q=Either+language%3Aswift&type=Code&ref=searchresults).
> 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 at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151212/334d0bbc/attachment.html>