Feature Request: OrderSet? about indexmap

[bluss]

Tell me if I'm too annoyingly eccentric.

1. My perspective on HashMap/HashSet is that it's annoying whenever one of them has methods that the other one doesn't. For example: key retrieval, for example: intersection, My goal would be to define operations so that they are available on both as far as possible.
2. It's still a young library, focus is still on completing the hash table before expanding.

[alexbool]

I came from Java/Scala world, so I may be a little biased.

1. You use Map, when you want to get value by key, and Set when you have a bag (collection) of (scalar) elements. So these are different use cases, I don't see how one can be annoyed by different APIs, like you don't complain on hammer when hammering nails or saw when cutting a plank.
2. This is true, but I don't see how it blocks OrderSet

P.S. Java's Map has a .keySet() which gives you a view into keys, so you can easily and free of charge get a set from a map.

[bluss]

these are not hammers and saws but closely related. In Java and Scala it's easy to have multiple references to a value, but in Rust the most sensible option might be HashSet<K> where in Java you'd use a Map<K, K>.

This also extends to the situation when the Key is placed internally as part of a struct. In that situation HashSet<FooStruct> / HashMap<FooStruct, ()> can be the better solution in Rust.

[alexbool]

To be honest, I still do not quite understand what you're trying to say. My position is that this Map and Set are engineered for different use cases (thus different interfaces), they may have similar implementations under the hood though.
I do not treat implementing OrderSet as expanding, becuase I expect quite a bit of code reuse with OrderMap (please tell me if I'm wrong). Also there is no such thing as collection framework in Rust (defined like in Java with a set of interfaces), but there is a set of de facto practices (stdlib's {Hash,BTree}{Map,Set}), and adding OrderSet may follow this practice.

[bluss]

To illustrate what I was trying to say:

How do you in Rust solve a map that implements interning (map to canonical instance of a string) without having two copies of each String? So you want to avoid having HashMap<String, String>.

Which of HashMap<String, ()> or HashSet<String> would you use for this?

[alexbool]

I had to solve exactly this task a week before and I have used HashSet<String>

[bluss]

That sounds like a compromise with Rust's ownership semantics, since it's really a string to string mapping.

[alexbool]

Precisely I used HasSet<Arc<String>>, but ownership seems to be completely orthogonal to Map/Set API discretion

[bluss]

How can you say that when you use a HashSet in a way that is outside the typical set interface? Retrieving a reference to the equivalent key is not a typical set operation, that's a string to string mapping operation. Java's Set doesn't have that operation.

[alexbool]

First, the code:

let incoming_string: Arc<String> = ...;
let mut interning: HashSet::<Arc<String>> = ...;

// ...

if interning.contains(&incoming_string) {
    return interning.get(&incoming_string).cloned().unwrap();
} else {
    interning.insert(incoming_string.clone());
    return incoming_string;
}

The only API used is Set's contains/insert. I use Set because there are only keys, no values. (Yes, you can view this as mapping from String key to String value, but generally you want to keep any outstanding references on duplicate keys as short as you can, so I used this approach)

So what are you trying to tell? Could it be done using HashMap<T, ()>? Yes. But if there's an easy way to provide an utility class that makes life a bit easier and less verbose in use case of "only keys, no values", then why don't we make it? And so many other libraries (Rust's stdlib, Java, Scala, C++ at least) do provide such abstraction.

[bluss]

There's a .get() there, not just contains and insert. What I mean is that there is no get in Java's Set.

Both of HashMap<String, ()> and HashSet<String> represent this compromise with Rust's ownership. In a language where everything is a reference (like Python or Java), you could use map from String to String instead.

[joshtriplett]

I'd similarly like to have an OrderSet<T> that uses OrderMap<T, ()> underneath, just as HashSet uses HashMap.

I don't consider that a map from T to T; I consider it a set of T.