|
|
|
|
|
|
by SamReidHughes
3882 days ago
|
|
|
We have proof in this very thread that people don't use the term HKT that way. That makes sense, because that's not what the words "higher kinded types" mean. > Saying C++ has HKT because it doesn't have typeclasses I didn't say anything like that at all. C++ has HKT, and it doesn't have type classes. |
|
|
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.