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

Joe Groff jgroff at apple.com
Thu Jan 28 12:49:46 CST 2016

> On Jan 26, 2016, at 10:59 PM, Dave Abrahams via swift-evolution <swift-evolution at swift.org> wrote:
> on Mon Jan 25 2016, Developer <swift-evolution at swift.org <mailto: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.

I agree. I also think that, if we ever do become interested in shape-generic programming, a more approachable way to expose it would be via D- or Clay-style metaprogramming type traits that provide generic access to the shape of types. Most users want to program in terms of concrete named types, and if they want to take advantage of generic frameworks, they aren't going to want to marshal back and forth between their concrete domain types and abstract Either<Either<...>> pyramids, or worse, write their code up-front in that style.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160128/edaccba7/attachment.html>

More information about the swift-evolution mailing list