[Manishearth]

If you consider `template<template ...>` to be HKT then Rust has this too. Rust macros can be used like C++ templates (minus autoinstantiation) and they can take other macros as parameters. It's not as nice as C++, but ... workable.

Patrick is talking about HKTs which can be typechecked at the source, similar to the rest of Rust generics, when he talks about "they want to create typeclasses that abstract over types of a higher kind and only those types". C++ templates get typechecked at use-time, not instantiation-time, like Rust macros. On the other hand, Rust forces you to constrain types in generics (a la C++ "concepts") so that it typechecks at the source (and then the contract for types being passed into the function is clear in the signature). We don't have higher kinded bounds, though.

HKT, after all, is a comment on bounds. What sort of things are you allowed to substitute for this generic or template parameter?

What seems to be happening here is a difference of opinion on what constitutes a "bound", in the C++ world a "structural" bound (i.e. type vs number vs template) is all you have. In the Rust world this isn't considered a bound, since the bound isn't type-safe. In the Rust world, Haskell world, and most other worlds where the word "kind" is used, a bound is a "type" (typeclass) bound and is type safe -- you can only do operations on the parameter which the bounds let you. Many Rust/Haskell people would consider C++ templates to be a particularly awesome macro system (but not a generics system); since they're structural-bound (like Rust macros); not type-safe.

Really a matter of terminology though.

[pcwalton]

Exactly. If C++/D have HKT, then so does Rust via its macro system.

[SamReidHughes]

C++ and D do it differently, I don't know why you're lumping them together. (Well, actually, I lied, I do know why.)