[Pre-RFC] Abandonning Morals In The Name Of Performance: The Raw Entry API


#41

The question is whether using these functions can lead to other safe code invoking undefined behavior. For example, Vec::set_len does not invoke undefined behavior, but a consequence of using it incorrectly is that calling some other safe Rust methods might invoke undefined behavior. That is, Vec::set_len allows you to break Vec's invariants in such a way that it could lead to undefined behavior in safe Rust later on.


#42

My understanding is they can’t. HashMap is currently implemented entirely using safe code* by making it a wrapper around RawTable (which is basically "just a tricked out Vec<Option<(u64, K, V)>>"). The changes we’ve been discussing would presumably all be at the HashMap level and thus be similarly safe.

*except for the the experimental implementation of collection_placement


#43

@fintelia does this mean that none of the proposed changes can result in undefined behavior being invoked, and that the only consequences of breaking the invariants of these collections is potential logic errors?


#44

Yes, the proposed changes can introduce potential logic errors but cannot trigger undefined behavior. In fact, the potential logic errors are the same ones that are already possible if the key’s Hash implementation does not respect the required invariants. (e.g. you’ll see some very strange behavior if keys that are equal can produce hashes that aren’t.)


#45

Then that’s great news, they don’t even need to be unsafe. A doc warning would be enough.


#46

@Gankro do you think there’s any chance we might see this kind of lower-level API surface? We’re currently relying on a painful-to-maintain fork of HashMap in rahashmap to get randomized eviction from a map for use in a cache…


#47

I’ve had https://github.com/rust-lang/rust/pull/50821 up for a while, but i’ve been waiting on more libs team feedback to finish it.


#48

That’s awesome! Looks like @alexcrichton followed up on it with a question about the safety of the API?


#49

They closed it just now saying that they were waiting for you? Seems like there’s been some miscommunication here?


#50

In the rust-lang/rust repo the triage team will close any PR where the author is unresponsive for more than two weeks. This doesn’t mean the PR won’t be accepted, it’s just a way for us to keep the list of open PRs clean. If the author wants to continue working on that PR we’ll be happy to reopen it!