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

[Andrey Tarantsov]

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

Now we're talking.

The stupid names are my biggest beef with FP. (The second biggest one is having to deal with mundane details of something outside of the problem domain.)

This, for example:

>     public func useFutures() {
>         downloadURLInFuture()
>             .flatMap(processContentAsync)
>             .flatMap { $0.calculateSomethingAsync() }
>             ...
>             .onComplete { finalProduct in
>                 print(finalProduct)
>             }
>     }

should use 'then' or 'after' or whatever.

Yes, I can understand that FP is powerful because you get some operation implementations for free (and you can have entire libraries of things that compose well). At the same time, the end result is, to me, subpar, because instead of domain-specific operations you're now using generic ones.

I don't want Swift to encourage this style; I don't want the most common promises library to use flatMap instead of then, just because Swift give them tools to do it more easily. The prevalence of those stupid operations in Rx-style libraries is already bad enough.

> It’s my understanding that these unruly double-Optionals are required in various parts of the Swift library. In particular with generators – a generator knows it’s got to the end when it encounters nil (.None). If it were only possible to have one level of Optional it would be impossible to enumerate an Array of Optionals. For example
> 
> [1,2,nil,4,5]
> 
> Without the ability to represent .Some(nil), the generator would reach the end after ‘2’ in the Array and would never get to ‘4’, ‘5’.

This, by the way, is the inherent conflict between the generic, metaprogramming-enabling language and an applications language. I want the distinction in generic code, but I don't really want that distinction in my normal code.

I'm concerned that the more meta stuff we add, the more profound this effect will be.

But if you guys promise to not apply the crazy FP stuff to every single computing task, I'm ready to vote neutral. (This voting is meaningless, of course, because we're likely more than a year away from considering these changes seriously.)

A.