3 ms·

I'm not that familiar with Rust, but what is the rational against higher-kinded types? Is it a technical limitation that everyone agrees is a limitation, or is

by mruts 8y ago

I'm not that familiar with Rust, but what is the rational against higher-kinded types? Is it a technical limitation that everyone agrees is a limitation, or is there some rationale why higher-kinded types in Rust are not useful? This is probably not relevant, but as a professional Scala programmer, I find higher-kinded types absolutely indispensable. Without them, writing truly generic (and imo, beautiful) code is almost impossible. Programming with higher-kinded types does really feel like some "next level shit." higher-kinded types are to types as first-order functions are functions: the natural and logical extension that unlocks simplicity, genericity, and beauty.

steveklabnik 8y ago
> what is the rational against higher-kinded types? There isn't so much a rationale against them, but rather, nobody has put forward a coherent proposal for them. Changes only happen when proposals are made and accepted, and there's never really been one for HKT. That said, there are arguments that apply fairly generally that would apply there too, namely "is the additional complexity worth it"?
comex 8y ago
Generic associated types are equally expressive to higher-kinded types while being more straightforward to implement on top of Rust's existing syntax. Adding true higher-kinded types in the future is not out of the question, but you'd need to add new syntax to declare them, which represents a fair bit of complexity for something that may not be necessary. There are also questions about ambiguities with respect to default parameters. If you have struct Foo<A = i32>(A); you can currently write `Foo` to refer to `Foo<i32>`, but what if you meant to refer to the higher-kinded type `Foo` itself? It could be determined based on context, but that would be somewhat confusing, and might not be possible in all situations (like when declaring type aliases, or if a way is ever added for a parameter to accept multiple kinds).

by mruts 8y ago

steveklabnik 8y ago

> what is the rational against higher-kinded types? There isn't so much a rationale against them, but rather, nobody has put forward a coherent proposal for them. Changes only happen when proposals are made and accepted, and there's never really been one for HKT. That said, there are arguments that apply fairly generally that would apply there too, namely "is the additional complexity worth it"?

comex 8y ago

Generic associated types are equally expressive to higher-kinded types while being more straightforward to implement on top of Rust's existing syntax. Adding true higher-kinded types in the future is not out of the question, but you'd need to add new syntax to declare them, which represents a fair bit of complexity for something that may not be necessary. There are also questions about ambiguities with respect to default parameters. If you have struct Foo<A = i32>(A); you can currently write `Foo` to refer to `Foo<i32>`, but what if you meant to refer to the higher-kinded type `Foo` itself? It could be determined based on context, but that would be somewhat confusing, and might not be possible in all situations (like when declaring type aliases, or if a way is ever added for a parameter to accept multiple kinds).