4 ms·
> Actually higher kinded types are easier than "generic associated types". Rust leans heavily on associated types in general, and there are several concrete us
by comex 6y ago
> Actually higher kinded types are easier than "generic associated types".
Rust leans heavily on associated types in general, and there are several concrete use cases where generic associated types are sorely missed (especially involving lifetimes).
You might ask, why not both? Part of the reason is conservatism about language features, and wanting 'only one way to do it'. But another part is that Rust is starved for compiler implementation manpower. The current generic associated types RFC was proposed in 2016 and merged in 2017, and it's a highly prioritized feature. But implementation work didn't even start until sometime in 2019 (AFAIK), and it still has a ways to go.
There's also another, somewhat more mundane problem...
Higher-kinded types somewhat conflict with default type parameters. If you have
struct Foo<T = i32> { t: T }
then you can currently write
Bar<Foo>
and it's equivalent to Bar<Foo<i32>>. So how do you distinguish that from passing the Foo constructor itself?
It may be possible to just distinguish based on context, but it's an issue.
- Ericson2314 6y agoI'm all for having generic associated types too, but by your own argument > Part of the reason is conservatism about language features, and wanting 'only one way to do it But for the things HKTs are good for, it's much more usable: easy to teach, simpler errors. Dare I say HKT is the conservative choice. > But another part is that Rust is starved for compiler implementation manpower. That's a bummer, and I wish you the best in finding new sources of funding. But if HKT is easier, that's another reason to do it first. > There's also another, somewhat more mundane problem... I don't think either of us thinks that is insurmountable :)