[swift-evolution] [proposal] Either in the Swift Standard Library

[Dave Abrahams]

on Mon Jan 25 2016, Developer <swift-evolution at swift.org> wrote:

> Because the shape is what matters to me most.  Whether the type is defined as 
>
> enum Either<L, R> { //... }
> enum Result<T, E> { //... }
> enum Choice<This, That> { //... }
> enum XOR<L, R> { //... }
> enum V<L, R> { //... }
> enum These<L, R> { //... }
>
> the point is that the standard library offers a sum type that doesn't
> attempt to invade the space taken over by throws (as I say in the
> proposal).  If we are to encourage that, then a type named Result that
> has a lobe specifically dedicated to error handling, in some cases
> even constrained by ErrorType, is an invasion indeed.  The type
> needn't carry semantics already provided by the language, and in that
> case it must carry the most general of semantics: those implied by
> structure and reinforced by documentation.
>
> As for bias, I'll admit that it is insufficiently addressed in the
> proposal (however I do acknowledge this very question would arise).
> We chose a left bias because of Rust's success and a lack of
> Haskell-style biased type application to deal with in type classes
> (not that we have any now anyway).  From a less technical perspective,
> the idea that an error should come first is counterintuitive.  It
> makes more sense to emphasize the successful case by placing it
> "first".
>
> I believe we disagree at such a level, outside of naming and what all
> that entails, because this seems like a Haskellism and Haskell's idea
> about error handling is opinionated to some and is made even more so
> by an implicit understanding required to interact with the rest of the
> ecosystem.  Either is not a fundamentally meaningless type in Haskell,
> or here, and it has a very precise interpretation computationally.
> Trouble is, conveying that sentiment also inevitably leads to
> incredibly technical arguments that leaves novices with a bitter taste
> - who wants to learn about Profunctors to figure out why Either had a
> right-bias anyhow?  The proposal is aimed towards the Swift community,
> not the Haskell one.

I think there is a Haskell-ism problem here, but it's not about Either.
Haskell is very concerned with the shape of types and generalizing
computations over those shapes, in a way that makes it hard for many
people to grasp semantics.  As cool as that way of thinking about
computation is, we want to keep Swift accessible.  Therefore, IMO we
really want to avoid introducing type-shape-oriented programming into
the core of swift.  Abstractions in the core of Swift should remain tied
to understandable semantics; for example, CollectionType.  Even after we
have higher-kinded types in the language—as I hope one day we will—I'm
skeptical that we'll want to define Monad or Arrow in the standard
library.

-- 
-Dave