<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Hi everyone, I read every post in the Higher-Kinded Types ( <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151214/002736.html" class="">https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151214/002736.html</a> ) thread from about a year ago, and I was wondering what's the status on the matter: I'm aware of the proposal draft ( <a href="https://github.com/typelift/swift/issues/1" class="">https://github.com/typelift/swift/issues/1</a> ), but I'd like to know if the Swift team has reconsidered the possible relevance of HKT for Swift in the foreseeable future.</div><div class=""><br class=""></div><div class="">By reading the discussion I found that the main concern from the Swift team was about practical use cases that could be of interest for a huge chunk of Swift developers: I don't think that a language feature should be there only if affects the majority of users, because of course you always have users at many different levels of awareness and understanding, not to mention experience and background, but I understand that, considering the time constraints in language development and proposals review, the focus should (initially) be on things that matter the most to the vast majority of developers.</div><div class=""><br class=""></div><div class="">But the idea of opposing a proposal because it's "hard to understand" (to some people, with different background) is baffling to me: there could be NO evolution whatsoever if everyone's only focus was on what feels familiar. But I don't want to talk about this: I just want to mention that if someone argues that they're not understanding a construct even if they consider themselves smart and experienced, that's their problem (maybe they're simply non experienced in that particular field), not a problem of the construct itself. And the fact that most things are mappable is not something functional programmers "believe": there's a huge corpus of research in the field of abstract mathematics that confirms this intuition. But anyway, let's move on.</div><div class=""><br class=""></div><div class="">I'd like to mention something that I consider a practical use case for the need of being able to express something like mappables and flatMappables in a abstract way: what's usually referred to as "monad transformers". I know that it's another concept that can be hard to grasp if you're not used to work with monads, but bear with me. Also, not sure about the etiquette here: it's an old discussion, but I wanted to offer my two cents.</div><div class=""><br class=""></div><div class="">Many functional programming techniques try to achieve true composability of code by decomposing logic in generic classes, that express a particular piece of that logic: the "Result" type ( <a href="https://github.com/antitypical/Result" class="">https://github.com/antitypical/Result</a> ) is a classic case (the same concept is similarly implemented by Swift throwable functions, but in a less composable way). There are many more types that do this, for example the Deferred type ( <a href="https://github.com/bignerdranch/Deferred" class="">https://github.com/bignerdranch/Deferred</a> ) was also mentioned in the discussion. Another type that I use a lot is the Writer type ( <a href="https://en.wikipedia.org/wiki/Monad_(functional_programming)#Writer_monad" class="">https://en.wikipedia.org/wiki/Monad_(functional_programming)#Writer_monad</a> ) that lets me accumulate an auxiliary result while executing an algorithm ( for example, generating an index path while traversing a tree ). And the Optional type is already in Swift. But while these types are useful by themselves, they become even more powerful when combined: for example, Deferred + Result is basically a Future, that is, an asynchronous computation that can fail. Even more interesting is a Deferred + Writer + Result (I going to refer to it as "DefWriRes"), something that I currently use while developing my HTTP clients, because I can accumulate information about request and response in a clean, composable way: unfortunately, mapping and flatMapping breaks when combining these types, because mapping a DefWriRes will require a function working on Writer, while I really just work on the type wrapped by the internal Result. Monad transformers work that way: they allow you to "go deeper" in combined monads. Now, the interesting thing is that to map a DefWriRes we only need to now that Deferred, Writer and Result are mappable, but without this abstraction I'm forced to copy and paste hundreds of lines of code (for every possible combination) where the only thing that changes is the type definition, because the method calls are just maps.</div><div class=""><br class=""></div><div class="">The case is similar for flatMap, so I need to call "flatMap" on something that's flatMappable, with the difference that I need to be able to unwrap the value in the Result (so I need to know how Result works, it's not just mapping), and I need to be able to create a "empty" Writer and Deferred (that's already achievable by the type system). But the case is similar, the only difference is that I need a specific "ResultTransformer" (I actually implemented this via protocols and constrained extensions, but the implementation details are not relevant for the case).</div><div class=""><br class=""></div><div class="">So what's the use case? If I was able to generically express a mappable and a flatMappable, I could combine those things multiple times at any level without rewriting the same almost identical code for every combination. And even if you're not a functional programmer, types like these are very useful to clearly and cleanly express the semantics of your code: in fact, the Optional type is extremely useful exactly for this, and I'm thankful for the fact that it is in the standard library, along with the respective map and flatMap methods.</div><div class=""><br class=""></div><div class="">What do you think? Thanks</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">Elviro</div></body></html>