Frank Steffahn

> Would it be possible to get hashbrown to assign a garbage hash to such entries instead? This would still be correct according to the garbage-in-garbage-out pattern of HashMap behavior...

If only one could somehow safely convert `&mut HashMap` into `&mut HashMap`, then it’d pe possible to make sure that during `FrozenMap::insert`, the `HashMap`-access happens through the `&mut HashMap`-view where...

> That _may_ be sound for `repr(transparent)` I think AFAIK that isn’t the case: For example, as far as I’m aware… ```rs pub struct HashMap { pub(crate) hash_builder: S, pub(crate)...

> Actually, one way to fix this would be a destructor guard type in `insert` that calls `mem::forget(mem::take(self))` or something. Usually panics don’t get converted in memory leaks, right? But...

By the way, your new title was inaccurate, as the problem only possibly arises on the *non-reallocating* rehashing ;-) This also makes this issue harder to run into. E.g. the...

> Another way to fix this would be to `catch_unwind` I guess; or potentially seed `insert` with a destructor bomb. Unsure what the perf implications of that are, and potentially...

Right, or if you modify it using the `AsMut` to do the deletions.

A possible fix is to use ```rust pub struct OwningRef, } ``` and ```rust pub struct OwningRefMut, } ``` see for example the draft PR #72.

On that note, I’m wondering what role the `thread_id` as part of the map’s *key* is playing in the `map_impl` version of the `registry`. Wouldn’t all entries get the same...

>The proposal makes unsafe code, that which is the most safety-critical code, easier to read, understand, and maintain. > >It also prevents preferring references over raw pointers. This prevents common...