Repository navigation
Add hashbrown refactor goal - #835
clarfonthey wants to merge 2 commits into
Conversation
|
A #goals/proposed topic was opened to discuss this issue. |
Co-authored-by: teor <teor@riseup.net>
|
|
||
| ## Summary | ||
|
|
||
| The `hashbrown` crate should be modernized and have most of its API surface moved to the standard library under the `alloc` crate. |
There was a problem hiding this comment.
| The `hashbrown` crate should be modernized and have most of its API surface moved to the standard library under the `alloc` crate. | |
| Modernize the `hashbrown` crate and move most of its API to the standard library under the `alloc` crate. |
|
|
||
| ### The status quo | ||
|
|
||
| Right now, the standard library's implementation of `HashMap` and `HashSet` rely on the implementation in the `hashbrown` crate. This crate contains both the hash table implementation and the concrete uses of `Map` and `Set`, but it also has a lot of APIs that have not been moved into the standard library which provide lots of real use cases like `entry_ref`, which allows using the `Entry` API without eagerly promoting types to their owned version. |
There was a problem hiding this comment.
| Right now, the standard library's implementation of `HashMap` and `HashSet` rely on the implementation in the `hashbrown` crate. This crate contains both the hash table implementation and the concrete uses of `Map` and `Set`, but it also has a lot of APIs that have not been moved into the standard library which provide lots of real use cases like `entry_ref`, which allows using the `Entry` API without eagerly promoting types to their owned version. | |
| Right now, the standard library's implementation of `HashMap` and `HashSet` relies on the implementation in the `hashbrown` crate. This crate contains both the hash table implementation and the concrete uses of `Map` and `Set`, but it also has a lot of APIs that satisfy real use cases and have not been moved into the standard library. For example, `entry_ref` allows using the `Entry` API without eagerly promoting types to their owned version. |
|
|
||
| Right now, the standard library's implementation of `HashMap` and `HashSet` rely on the implementation in the `hashbrown` crate. This crate contains both the hash table implementation and the concrete uses of `Map` and `Set`, but it also has a lot of APIs that have not been moved into the standard library which provide lots of real use cases like `entry_ref`, which allows using the `Entry` API without eagerly promoting types to their owned version. | ||
|
|
||
| The implementation for hashbrown is also very old, designed before the standard library had correctly described its semantics for `MaybeUninit`, without any safety comments for tracking the invariants held by its unsafe code. |
There was a problem hiding this comment.
| The implementation for hashbrown is also very old, designed before the standard library had correctly described its semantics for `MaybeUninit`, without any safety comments for tracking the invariants held by its unsafe code. | |
| The implementation for `hashbrown` is also very old, designed before the standard library had correctly described its semantics for `MaybeUninit`, without any safety comments for tracking the invariants held by its unsafe code. |
|
|
||
| ### What we propose to do about it | ||
|
|
||
| Simply put, the `hashbrown` crate needs a lot of work done to refactor its internals and audit unsafe code, with the end goal of effectively all of its API surface being moved into the standard library *and* ecosystem crates being able to start depending on the standard library instead of `hashbrown`. |
There was a problem hiding this comment.
What happens to hashbrown once that's done? Will it become obsolete for non-legacy purposes?
There was a problem hiding this comment.
I think that the point about API experimentation is still valuable, just, we'd have hopefully converted all the existing stuff from "experiment" to actually being stable
There was a problem hiding this comment.
I'm trying to grasp the diff between how the standard library, hashbrown, and external crates relate to each other today and after this goal (as someone who's unfamiliar with how that's set up).
Is the goal for hashbrown to become similar to itertools, where the standard library no longer depends on it and the ecosystem uses it for extra APIs that may or may not be upstreamed eventually? Or is it something else?
There was a problem hiding this comment.
So, at this point, hashbrown is an interesting situation. I think longer-term we do actually want to have big implementations for the standard library separated out into different crates, because we get the benefit of API experimentation (you can change the API without worrying about stability) and the ability to test out performance changes easily. There are also probably aspects of the implementation that might be useful to add for stuff like the compiler that aren't necessarily worth including in the standard library.
So, longer-term, hashbrown remains as it is, but the standard library is in a good place, and most people don't actually depend directly on it unless they want to experiment with the API or do very weird and cursed things with it, like the compiler.
Rendered