[swift-evolution] [Proposal] Higher Kinded Types (Monads, Functors, etc.)

Dave Abrahams dabrahams at apple.com
Wed Dec 16 14:38:35 CST 2015


> On Dec 16, 2015, at 12:15 PM, Will Fancher via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Could you elaborate on why you think it's out of scope? Maybe it's just me, but it seems like a very pressing feature. Being unable to write higher kinded abstractions has been a big issue with using Swift generics. It has been impossible to do various kinds of abstractions.

I would like to better understand which abstractions you are blocked from implementing (other than the basic HKTs themselves).  I understand how HKTs enable some more code reuse, but most of the abstractions that HKTs enable seem to be based on the structure of types rather than on semantics, which makes them:

a) hard to understand
b) hard to document
c) hard to compose into big “towers” of useful semantics. 

What I mean here is that there don’t seem to be many useful abstractions out there that can be built upon a “Monad” constraint (for example), and because “Monad” is such a general concept, when you *do* encounter such an abstraction it’s hard to understand what to do with it.
 
Therefore I have always thought that the costs in language and conceptual complexity vs benefits for HKTs is at least highly debatable.  I have occasionally bumped up against the lack of HKTs, but IMO broadly speaking our users are not suffering from the inability to express “Monad” but many of the other generics features we are lacking prevent even the components we *do* provide from functioning completely and properly (e.g. Arrays are never Equatable).

> It makes generics feel very incomplete, so I feel that it lines up well with the "complete generics" goal.

It does, but—just my personal opinion—it would probably be the first thing I would cut from the list when considering resource constraints.

-Dave





More information about the swift-evolution mailing list