[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