Rust 2020: Generics & cargo features

This is my personal wishlist of things I'd like to see in 2020 relating to Rust. It only contains technical items, not because I disagree with the people who say we should prioritize some non-technical things, but because I feel like I don't have much of value to add to that topic.

Generics

My absolute top one wishlist feature: const generics. The language I'm most proficient in other than Rust is C++ and its equivalent feature (with the beautiful name of 'non-type template parameters') is one of the only things I miss in Rust from time to time. And while most of the things I'd like to do with it can be done using typenum, it can result in quite long type names, which makes error messages including those types very hard to read.

I'd also love to see GATs coming to nightly next year. Since they are required for async fn in traits, I have my hopes up for this happening. Then again, async fn is a really hard problem even with GATs available, so they might not get prioritized until the path forward is clearer. Either way, I'd love to play around with them.

Cargo features

There's a few long-standing issues in cargo that all relate to the idea of one feature-set per (transitive) dependency. On first thought, it seems reasonable to require tests to run with dependencies compiled with the same feature set that's used when distributing your app or library as a release build. However, once you consider build scripts and no_std , this doesn't work so well anymore.

A prime example of this issue is serde_json, which has a hard dependency on std, purely because dev-dependencies and regular dependencies have their features unified (see serde/json#516). There's of course a reason that these issues have been open for so long, and that is that it would require a big rewrite of some parts of cargo. I don't know what needs to happen for this rewrite to start, but I'd love to see (some of) these issues finally being resolved in 2020.

Another unfortunate thing about cargo features is that enabling a feature of an optional dependency also enables that dependency (rust-lang/cargo#3494). AFAICT, solving this doesn't require any big rewrites, just a consensus on which way to solve it.

IDE experience

This one didn't make it into the title, but I'd nevertheless like to see the IDE experience improve further. RLS is already more useful than Microsoft's C/C++ extension in Visual Studio Code, but some things seem like they are still somewhat far away from their possible best: edit-to-feedback time, autocompletion, and finding item definitions on mouseover are all things I'd like to see improved next year (and I think they will be).

Conclusion

Most people reading this will already have come across const generics, GATs as well as the cargo and RLS issues I wrote about. I didn't write about new ideas I think should be tried out, because I think Rust doesn't need these kinds of changes at the moment. I agree with the previous Rust 2020 blog posts that called for another year of maturity. Let's leave the anonymous records; effects; linear, dependent and higher-kinded types and whatever else for later.

Thanks for reading!