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

[Brent Royal-Gordon]

> For the programmers without functional programming background HKTs gonna be misleading and non-readable. A thousand similar analogies: "<OneMonad> can be seen as <OtherMonad>" will need to be made. Those analogies are gonna break (for example, how would one explain monad transformers in those terms?) and lead to even more confusion. 

Believe it or not, I’m actually *not* one of the functional astronauts who believes everything is a `map`. I can sometimes understand what they’re getting at, usually after reading about a dozen different “simple” explanations of a concept, but I think the human factors on the foundations of functional programming are an unmitigated disaster, and that many functional programmers are in deep denial about that. That’s why, when I wrote a Result type, I didn’t give it `map` and `flatMap` operations; I called them `convert` and `then`, to at least try to give some indication of what they actually mean in your code.

Nevertheless, I think the functional view is *useful* and *powerful* so long as it’s also *optional*. Swift should not start emitting sarcastic error messages about monoids in the category of endofunctors, but that doesn’t mean it shouldn’t *permit* people to use these things when they want to.

Support for higher-kinded types merely means that Swift will permit people to do weird abstract functional programming—and a few neat tricks that are more down-to-earth, like a collection-type-preserving `map`—if they want to. It won’t mean *you* will have to. I don’t think this feature is urgent, but I hope it’s supported eventually.

And I hope someone figures out a better name than “monad”. Ugh.

-- 
Brent Royal-Gordon
Architechies