Repository navigation
Add BTree parity goal - #836
Open
clarfonthey wants to merge 3 commits into
Open
clarfonthey wants to merge 3 commits into
clarfonthey wants to merge 3 commits into
Conversation
Collaborator
|
A #goals/proposed topic was opened to discuss this issue. |
teor2345
reviewed
Oct 26, 2026
Co-authored-by: teor <teor@riseup.net>
Co-authored-by: teor <teor@riseup.net>
nxsaken
reviewed
Oct 26, 2026
|
|
||
| ### The status quo | ||
|
|
||
| Right now, the standard library's implementation of `HashMap` and `HashSet` relies on the implementation in the `hashbrown` crate. This has been a very healthy relationship, since it means that the ecosystem can easily suggest changes to ergonomics of the implementation and expose its inner workings without having to deal with the extremely strict stability guarantees of the standard library. There are several ecosystem crates that are able to build upon this work for other primitives like `indexmap` (hash tables with ordered entries) and `dashmap` (concurrent hash tables). |
Contributor
There was a problem hiding this comment.
Some background about how the standard library started relying on hashbrown (and maybe linking to related issues/PRs) would be a good setup for the proposal below.
|
|
||
| Right now, the standard library's implementation of `HashMap` and `HashSet` relies on the implementation in the `hashbrown` crate. This has been a very healthy relationship, since it means that the ecosystem can easily suggest changes to ergonomics of the implementation and expose its inner workings without having to deal with the extremely strict stability guarantees of the standard library. There are several ecosystem crates that are able to build upon this work for other primitives like `indexmap` (hash tables with ordered entries) and `dashmap` (concurrent hash tables). | ||
|
|
||
| In the standard library, we also have the types `BTreeMap` and `BTreeSet` for an analogous data structure, however, these types have languished a lot because they don't have the benefit of being an external crate like `hashbrown`. This has lead to a lot of anxiety when it comes to working on these types: several features have been "put off" for their implementation due to the complexity of the current code (custom allocator support, cursors, etc.) and many downstream users are limited in the ways they can leverage these primitives due to the lack of robust APIs. |
Contributor
There was a problem hiding this comment.
Suggested change
| In the standard library, we also have the types `BTreeMap` and `BTreeSet` for an analogous data structure, however, these types have languished a lot because they don't have the benefit of being an external crate like `hashbrown`. This has lead to a lot of anxiety when it comes to working on these types: several features have been "put off" for their implementation due to the complexity of the current code (custom allocator support, cursors, etc.) and many downstream users are limited in the ways they can leverage these primitives due to the lack of robust APIs. | |
| In the standard library, we also have the types `BTreeMap` and `BTreeSet` for an analogous data structure, however, these types have languished because they don't have the benefit of being an external crate like `hashbrown`. This has led to a lot of anxiety when it comes to working on these types: several features have been "put off" for their implementation due to the complexity of the current code (custom allocator support, cursors, etc.) and many downstream users are limited in the ways they can leverage these primitives due to the lack of robust APIs. |
Comment on lines
+11
to
+13
| Right now, the standard library has the benefit of the `hashbrown` crate: a modern hash table implementation that can be reused by the ecosystem for more complicated situations, which is explicitly used for the libstd `HashMap` and `HashSet` types. | ||
|
|
||
| A very related set of types, `BTreeMap` and `BTreeSet`, currently have gotten so overbearing in the standard library that they have a bit of a reputation of being hard to deal with. We should fix this, both factoring the implementation out into its own crate where the API can be experimented with more easily, and to resolve concerns on custom allocators, cursors, and other desired APIs. |
Contributor
There was a problem hiding this comment.
The summary should be something roughly like this:
Suggested change
| Right now, the standard library has the benefit of the `hashbrown` crate: a modern hash table implementation that can be reused by the ecosystem for more complicated situations, which is explicitly used for the libstd `HashMap` and `HashSet` types. | |
| A very related set of types, `BTreeMap` and `BTreeSet`, currently have gotten so overbearing in the standard library that they have a bit of a reputation of being hard to deal with. We should fix this, both factoring the implementation out into its own crate where the API can be experimented with more easily, and to resolve concerns on custom allocators, cursors, and other desired APIs. | |
| Move the implementation of `BTreeMap` and `BTreeSet` into a separate crate similar to `hashbrown` and bring their APIs to parity with `HashMap` and `HashSet`. |
| @@ -0,0 +1,61 @@ | |||
| # `BTree` feature parity | |||
Contributor
There was a problem hiding this comment.
This is a bit unclear. I think it needs some reference to hashbrown or HashTable, the former probably conveys the idea of this goal better.
Something like this?
Suggested change
| # `BTree` feature parity | |
| # Hashbrownify `BTree` types |
Author
There was a problem hiding this comment.
This is an extremely cursed naming and I'm not sure if I want to accept it yet, but, will ponder it
| | :--------------- | ------------------------------------------------------------- | | ||
| | Contact | @clarfonthey | | ||
| | Status | Proposed | | ||
| | What and why | Make `BTree` types as robust as their `HashTable` equivalents | |
Contributor
There was a problem hiding this comment.
Suggested change
| | What and why | Make `BTree` types as robust as their `HashTable` equivalents | | |
| | What and why | Make `BTree` types as robust as their `hashbrown` equivalents | |
Author
There was a problem hiding this comment.
Yeah, makes sense; HashTable is currently only offered in hashbrown but we do have an active ACP for BTree.
At this point, I mostly just need to flesh these out with existing issues/etc. for more context.
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Rendered