Issue by treeman
_Monday Jul 14, 2014 at 20:12 GMT_
_For earlier discussion, see https://github.com/rust-lang/rust/issues/15669_
_This issue was labelled with: A-libs, I-enhancement in the Rust repository_
Extensions to treemap and hashmap, with set variations. Indicated by the wiki.
It looks like there's a pretty decent go at this already at https://github.com/havarnov/multimap
(Note: that's not me.)
Should this be closed?
Please No. I don't want to use external. If rust provides and supports or even merge this project then we can use it. external crate may die anytime as mostly one guy support so for core features like this one there should be some internal support. Almost all langs supports this.
cc @rust-lang/docs Perhaps it would be useful to have, somewhere in a FAQ, an explanation of how external crates are not bound to be of worse quality and less maintained than libstd proper?
Or if there is one already, could you link it here?
@codeyash Are you sure "almost all langs" do in fact support that? None of Python, D, Java, Ruby, Go, PHP, Javascript, Perl, or Swift provide multimaps in their standard libraries.
@codeyash: Qt is not a language; it's a library written in C++. A Rust equivalent would be on crates.io, not in the stdlib; just as Qt is available as a separate package, and not as part of libstdc++, libc++, or the Microsoft C++ standard library implementation.
On the other hand, in Rust, a library like Qt would almost certainly be split out into _multiple_ crates; much as Qt has been splitting itself first into separate libraries for different functionalities (Qt 3 -> Qt 4) and then further into separately-installable packages (Qt 4 -> Qt 5).
In short: If you don't find using Qt for its multimap objectionable in the C++ world, there is no defensible reason to object to using a Cargo crate for it in the Rust world. (Heck, Rust makes it easier, because we have a powerful dependency manager that C++ lacks. Getting Qt set up for development can be painful unless you either use a distro package or use a Qt-themed development environment.)
@eternaleye I admire your points. Its seems you are saying everyone is walking in one single straight line and we should also in order to maintain rules. :)
Qt is totally different topic. I'm advance user. QMultimap, QHashMap are really important packages. As per Qt we should use Qt libraries if available and not plain c++. Qt Multimap can't be used without Qt. Qt maintains its framework. Qt is not just library. It contains full eco system like compiler, moc objects etc anyways lets leave Qt out from this discussion.
Everyone is ready to debate and told me to follow trends and do what others are doing. This is not engineering. This is something else. Be unique. Rust is unique in its style and approach. I really appreciate creators thinking. Many guys debate with me why OOPS better and rust lacks. All these guys want to see traditional and wants to follow what is everybody is following. I don't.
I raised a bad point other langs are using. I'm taking my words back. Forget that point.
Why we should or shouldn't include here, please add points.
@codeyash: To address your points one by one:
As an implementation exists in https://crates.io/crates/multimap and T-libs did not seem interested in moving this into the standard library I am closing this.
Most helpful comment
@codeyash Are you sure "almost all langs" do in fact support that? None of Python, D, Java, Ruby, Go, PHP, Javascript, Perl, or Swift provide multimaps in their standard libraries.