Cautiously consolidating the standard library

libs
4

There's also Pre-RFC: Expressive Standard Library Paths, which was a variant of this in a way. I'll repeat what I said there, because I think it applies here:

I've always thought that most of the submodules that std exports felt like irrelevant implementation details that were being leaked to the public API. There are submodules that only have one type/trait they export (e.g., std::default ), types/traits in submodules for reasons that aren't obvious to me (I'm still not sure why ManuallyDrop and MaybeUninit are in the mem submodule), and types/traits that are split across multiple submodules rather than being grouped together (e.g., some operators live in core::cmp and others live in core::ops ).

I'd love to be able to write std::HashMap instead of having to remember it's in collections, among many other things. And I agree with kornel that having multiple paths to the same type/trait can lead to confusion because it's not immediately clear if they're the same or different.

When conversations like this come up, I have two questions:

  1. If we were to go back in time and start over, what would std's public API look like?
  2. Given that we can't go back in time and the cat's already out of the bag, what would a realistic compromise or solution look like?
12 Likes