Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement a multimap #784

Closed
steveklabnik opened this issue Feb 2, 2015 · 10 comments
Closed

Implement a multimap #784

steveklabnik opened this issue Feb 2, 2015 · 10 comments
Labels
A-community-library Area: The RFC is related to a community library. T-libs-api Relevant to the library API team, which will review and decide on the RFC.

Comments

@steveklabnik
Copy link
Member

Issue by treeman
Monday Jul 14, 2014 at 20:12 GMT

For earlier discussion, see rust-lang/rust#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.

@steveklabnik steveklabnik added A-community-library Area: The RFC is related to a community library. A-enhancement and removed A-wishlist labels Feb 14, 2015
posborne added a commit to posborne/rust-pstree that referenced this issue Mar 4, 2015
This addresses the following feeback:

Your code looks really good, and very Rustic. I only have a few comments:
· In ProcessRecord you use isize for the pid and ppid. These aren’t really sizes, so I’d go with i32
· Line 102: since all you’re doing is panic!() on Err, you can just use .unwrap()
· Line 107: you could use “filter_map” instead of filter and then “collect” the results. This eliminates the need for “mut records” on line 98
· Line 126: use “filter_map”
· I’d add Cargo support
· You could consider using a map type containing vector types for storing the ppid->pid translation. That would improve performance since the record list wouldn’t getting iterated over multiple times. Unfortunately Rust doesn’t have a multimap yet (see rust-lang/rfcs#784), otherwise you could just use that!

Using a map type for the lookup is not supported with this but will
be evaluated.
@carycodes
Copy link

It looks like there's a pretty decent go at this already at https://github.com/havarnov/multimap
(Note: that's not me.)

@cflewis
Copy link

cflewis commented May 18, 2016

Should this be closed?

@codeyash
Copy link

codeyash commented Jul 9, 2017

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.

@eddyb
Copy link
Member

eddyb commented Jul 9, 2017

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?

@sfackler
Copy link
Member

sfackler commented Jul 9, 2017

@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
Copy link

codeyash commented Jul 9, 2017

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

@eternaleye
Copy link

eternaleye commented Jul 9, 2017

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

@codeyash
Copy link

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

@eternaleye
Copy link

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

@petrochenkov petrochenkov added T-libs-api Relevant to the library API team, which will review and decide on the RFC. and removed A-libs labels Jan 29, 2018
@Centril
Copy link
Contributor

Centril commented Oct 7, 2018

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.

@Centril Centril closed this as completed Oct 7, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-community-library Area: The RFC is related to a community library. T-libs-api Relevant to the library API team, which will review and decide on the RFC.
Projects
None yet
Development

No branches or pull requests

9 participants