All collections, for clarity and for easiness of learning should be in std::collections. This is obvious namespace. That's why collections like HashMap and others are there.
As for vec being in prelude? Why? Actually, every non-trivial program uses HashMap too, why not put it HashMap in prelude too?
I'm not against putting HashMap into prelude. Actually I think it's really nice to have. But it's another topic. Historically, the Vec<T> is so special as it has its own syntax - it was ~[T]. This would be the root source why it has its own module.
I do agree that std::collections::vec would be nicer than std::vec. What I dislike is to have both path available.
I feel this is rapidly going down a path where you just argue with every point and try to convince everyone that this is a huge wart that must be fixed (but not by you, apparently, because it's "not your language"), so I'm not going to continue to engage in this thread. But specifically in reference to this:
This has been discussed in the past and opinions are fairly split. I personally disagree with the premise that every nontrivial program needs a HashMap, but I wouldn't necessarily be opposed to putting it in the prelude. (Note that std::collections::BTreeMap also exists.) There was a PR last year, which was closed due to the lack of an accepted RFC.
3 Likes
Tbh, I personally go the other way. I think collections shouldn't be in the std. It contains the sort of data structures that are better done by third party crates.
But I'm sold on the idea of a minimal std. Though I know many people aren't to the same degree that I am.
1 Like
This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.