2020-04-07 Rust: The unfortunate bits

This is an assortment of unfortunate, regrettable decisions made by the Rust standard library. They're all very minor, inconsequential things - gotchas that you notice the first time you hit them and then learn to live with them. So this article isn't meant to be a rant or anything of that sort. It's just a list that's been mulling in my mind for a long time that I decided to put to paper. I've also needed to reference these points when talking on IRC, so it'll be easier to just provide URLs.

I link to the libstd docs when relevant, but I assume basic Rust knowledge from the reader.

This list is neither objective nor complete. It's built from my own experience using Rust since 2016, as well as the discussions I've seen in its IRC channels involving experienced users and new users alike.

All of these things could be resolved in a Rust "2.0", ie a release that is allowed to make backward-incompatible changes from the current "1.x". I personally hope that such a release never happens, despite being the author of this list, because I don't know any backward-incompatible forks of languages that have gone well. The editions system that Rust has cannot be used to fix these, because every crate uses the same libstd regardless of what edition it has. Hypothetically, libstd could be made to appear differently to crates depending on what edition they're compiled for, but this is not a feature that exists today or may ever exist. It would also cause even greater havoc with macros than the 2015 -> 2018 edition transition did, because things like trait impls are program-global, not crate-scoped.

Changing these would be backward-incompatible

These can't be changed, but they can be deprecated in favor of new alternatives