Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Relax bounds on some metrics_util::registry::Registry methods #484

Merged
merged 1 commit into from
May 11, 2024

Conversation

david-perez
Copy link
Contributor

I was thinking through #481 when I noticed this possible bounds relaxation.


The Registry struct definition requires K: Hashable, which is
superfluous since it's already required in the impl block.

Moreover, some methods don't require the full K: Clone + Eq + Hashable
bounds. Some methods only require K: Eq + Hashable, others only
require K: Hashable, while others don't require any bounds at all on
K.

This commit splits the single impl block into three impl blocks, so
users that have keys that don't satisfy all bounds can still make use of
some methods.

The `Registry` struct definition requires `K: Hashable`, which is
superfluous since it's already required in the impl block.

Moreover, some methods don't require the full `K: Clone + Eq + Hashable`
bounds. Some methods only require `K: Eq + Hashable`, others only
require `K: Hashable`, while others don't require any bounds at all on
`K`.

This commit splits the single impl block into three impl blocks, so
users that have keys that don't satisfy all bounds can still make use of
some methods.
@@ -47,7 +47,6 @@ type RegistryHashMap<K, V> = HashMap<K, V, BuildHasherDefault<RegistryHasher>>;
/// `Registry` is optimized for reads.
pub struct Registry<K, S>
where
K: Hashable,
S: Storage<K>,
{
counters: Vec<RwLock<RegistryHashMap<K, S::Counter>>>,
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Out of curiosity, why are we explicitly depending on a hashbrown::HashMap for this type? Isn't the standard library's identical?

Copy link
Member

Choose a reason for hiding this comment

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

std::collections::HashMap<K, V> is based on hashbrown now, yes, but we use the raw entry API, which is still not yet stabilized in the standard library.

Copy link
Member

@tobz tobz 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 to me. 👍🏻

@tobz tobz merged commit 82513b3 into metrics-rs:main May 11, 2024
12 checks passed
@tobz tobz added C-util Component: utility classes and helpers. E-intermediate Effort: intermediate. T-refactor Type: refactor. S-awaiting-release Status: awaiting a release to be considered fixed/implemented. labels May 11, 2024
@tobz
Copy link
Member

tobz commented May 27, 2024

Released in [email protected].

Thanks again for your contribution. 🙏🏻

@tobz tobz removed the S-awaiting-release Status: awaiting a release to be considered fixed/implemented. label May 27, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-util Component: utility classes and helpers. E-intermediate Effort: intermediate. T-refactor Type: refactor.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants