Skip to content

Conversation

@Peponks9
Copy link

Closes #696

@krushimir
Copy link
Collaborator

Thanks for working on this!

Since std::collections::HashMap is only available with std anyway, do we still need the hashmaps feature?

We could simplify by automatically using HashMap when std is enabled and falling back to BTreeMap in no_std environments.

This would give users the best performance by default while keeping no_std support, and we'd have one less feature to maintain.

What do you think?

Copy link
Author

@Peponks9 Peponks9 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the feedback guys. Good poin, I’ll remove the hashmaps feature and tie it directly to std.

Copy link
Contributor

@bobbinth bobbinth left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good! Thank you! I left a few small comments inline.

Also, I tried to resolve merge conflicts, but seems like it broke something. Could you please fix this?

executable = ["concurrent", "dep:clap", "dep:rand-utils"]
fuzzing = []
hashmaps = ["dep:hashbrown"]
internal = ["concurrent"]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Question: why did we make it so that concurrent doesn't imply std, and internal doesn't imply concurrent? Shouldn't this be more like:

concurrent = ["dep:rayon", "std"]
default = ["concurrent", "std"]
executable = ["concurrent", "dep:clap", "dep:rand-utils"]
fuzzing = []
internal = ["concurrent"]

Comment on lines 33 to 37
/// By default, this is an alias for the [`alloc::collections::BTreeMap`]; when the `std` feature is
/// enabled, this is an alias for the `std::collections::HashMap` (iteration order is not
/// deterministic in that case).
#[cfg(feature = "std")]
pub type Map<K, V> = std::collections::HashMap<K, V>;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the comment is not exactly correct here: by default, we enable std::collections::HashMap.

Comment on lines 44 to 47
/// By default, this is an alias for the [`alloc::collections::BTreeMap`], however, when the
/// `hashmaps` feature is enabled, this is an alias for the `hashbrown`'s `HashMap`.
#[cfg(not(feature = "hashmaps"))]
/// `std` feature is enabled, this is an alias for the `std::collections::HashMap`.
#[cfg(not(feature = "std"))]
pub type Map<K, V> = alloc::collections::BTreeMap<K, V>;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same comment as above: by default we enable std::collections::HashMap.

This is also relevant in a couple other places in this file.

@bobbinth
Copy link
Contributor

@Peponks9 - are you still interested in wrapping up this PR?

Copy link
Author

@Peponks9 Peponks9 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sure thing, working on it rn @bobbinth

Copy link
Author

@Peponks9 Peponks9 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

pushing changes soon

@bobbinth
Copy link
Contributor

@Peponks9 - after recent merges, there are now quite a few conflicts here - sorry about that! Would you be able to resolve them?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Consider removing hashbrown dependency

4 participants