Rfcs: Implement a multimap

Created on 2 Feb 2015  路  10Comments  路  Source: rust-lang/rfcs

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.

A-community-library T-libs

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.

All 10 comments

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.

@sfackler yes almost all is incorrect but I was talking about langs like C++, Scala and Qt

@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.

  1. My point and personal I use this feature a lot. Keeping and managing data is really easy. It enables me to create complex code with ease. Right now I'm using Vec or Custom Struct(inside Vec) in value in order to behave like multi but I think this is not a efficient method.
  2. Using external crate may be problem when security is your concern.
  3. Another personal I want to avoid external dependencies on code as much as possible.

@codeyash: To address your points one by one:

  1. You may well use this feature a lot; however, the level of activity on this issue seems to imply either that others _do not_, or that a crate satisfies their needs.
  2. Without external crates, you will be unable to write GUIs, use cryptography, obtain randomness, compress or uncompress data, work with images or audio, or any number of common tasks that are much more widely used than multimaps. If security is such a concern, it would be more productive to follow this issue, and perhaps contribute to rust-tuf.
  3. This is generally considered unidiomatic in Rust, and pulling things into the standard library to support it is thus unlikely. You may find cargo-vendor to be of interest.

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.

Was this page helpful?
0 / 5 - 0 ratings