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

Joe Groff jgroff at apple.com
Wed Dec 16 22:39:21 CST 2015


> On Dec 16, 2015, at 5:10 PM, Dave Abrahams via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
>> On Dec 16, 2015, at 1:34 PM, Douglas Gregor <dgregor at apple.com> wrote:
>> 
>> With higher-kinded types, one could potentially [*] produce a collection of the same kind as Self but with the element type T. So, mapping a Set produces a Set, mapping an Array produces an Array, etc. 
> 
> Yeah, but Set can’t follow the functor laws, so that map won’t apply to it.  That’s why, while I agree that this kind of constraint is helpful and important for completing the generics picture, IMO it is probably less helpful/important than many people think.

Looking beyond functional programming abstractions, higher-kinded types are a fancy way of saying "template template parameters". A textbook motivation for those from C++ land is Andrei Alexandrescu's "policy pattern", stuff like this:

protocol RefStoragePolicy: <*: class> {
  typealias Ref: class
  init(ref: Ref)
  var ref: Ref
}

struct Weak<T: class>: RefStoragePolicy { weak var ref: T }
struct Unowned<T: class>: RefStoragePolicy { unowned var ref: T }
struct Strong<T: class>: RefStoragePolicy { var ref: T }

class HeterogeneousRefConsumer<Storage: RefStoragePolicy> {
  func consumeRef<T: class>(ref: T) {
    let storage = Storage<T>(ref: ref)
    doStuffWith(storage)
  }
}

-Joe


More information about the swift-evolution mailing list