Yeah, whole-value-as-key isn't quite the right model for many cases. I'm really glad Rust has the expressive power to present a safe interface over some thorny internal code
Comments
Log in with your Bluesky account to leave a comment
I wasn't thinking about C/C++, haven't touched those in years.
But that pattern, of a set that is keyed on an immutable function of the content rather than the whole content is prevalent. At least I've written a lot of code like that, but yet had the 💡 to abstract.
If we assume the objects are immutable, then I don't imagine it being really ugly, unless I'm missing something.
Similar to the `key` argument in most Python sorting methods, or Java's Comparator.comparing() - for type T, define T→U that returns the key, pass it to the set constructor.
You can't use the existing interfaces because those expect the order imposed by implementations to be consistent with equals (that is, equal keys iff equal objects, which may not be true here).
But I don't see where there'd be much complexity in a new implementation. What am I missing?
At Oxide we've found that key changes have always been a bug, but we could probably provide a method to reinsert a RefMut. I'm hesitant to do automatic reindexing, though, it feels too magical to me.
My mental model of the API is that of a set, not map.
As such, for the user, it doesn't materialize as reindexing, as long as the property that at no point you have two objects that map to the same key holds.
Comments
But that pattern, of a set that is keyed on an immutable function of the content rather than the whole content is prevalent. At least I've written a lot of code like that, but yet had the 💡 to abstract.
Similar to the `key` argument in most Python sorting methods, or Java's Comparator.comparing() - for type T, define T→U that returns the key, pass it to the set constructor.
But I don't see where there'd be much complexity in a new implementation. What am I missing?
As such, for the user, it doesn't materialize as reindexing, as long as the property that at no point you have two objects that map to the same key holds.