<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><blockquote type="cite" class="">On 16 Dec 2015, at 11:11, Will Fancher via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class="">Hello,<br class=""><br class="">A potent problem in my experience with Swift has been the lack of a way to generalize code that is repetitive on the basis of higher kinded types. For the uninitiated, higher kinded types are the ability to reason about generic types with their type parameters as variable. </blockquote><div class=""><br class=""></div><div class="">For those thinking, “Hmm… What’s the benefit of all this crazy sounding stuff?”, there’s a rather good practical talk about Functors.</div><div class=""><br class=""></div><b class="">How I Learned to Stop Worrying and Love the Functor:</b><div class=""><a href="https://vimeo.com/132657092" class="">https://vimeo.com/132657092</a></div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">Here’s an example that is used:</div><div class=""><br class=""></div><div class="">func sayHello(name: Optional<String>) -> Optional<String> {<br class=""> return name.map { "Hello \($0)" }<br class="">}<br class=""><br class="">func sayHello(name: Array<String>) -> Array<String> {<br class=""> return name.map { "Hello \($0)" }<br class="">}</div><div class=""><br class=""></div><div class="">It doesn’t use the usual syntax sugar for Optionals and Array, to make it clear that the only difference between the 2 functions is the type signature. If were possible to express the concept of a Functor, we could write one function that would accept both Optionals and Arrays as parameters – and not just those 2, but any Functor (Result, Future, Signal…).</div></body></html>