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

Improve consistency of derive(Byte*) documentation #2306

Open
wants to merge 1 commit into
base: v0.8.x
Choose a base branch
from

Conversation

jswrenn
Copy link
Collaborator

@jswrenn jswrenn commented Feb 6, 2025

This edit brings the structure of these docs in line with that used for our other derives.

This edit brings the structure of these docs in line with that
used for our other derives.
@codecov-commenter
Copy link

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 87.46%. Comparing base (3ad056b) to head (f10667e).
Report is 2 commits behind head on v0.8.x.

Additional details and impacted files
@@           Coverage Diff           @@
##           v0.8.x    #2306   +/-   ##
=======================================
  Coverage   87.46%   87.46%           
=======================================
  Files          16       16           
  Lines        6134     6136    +2     
=======================================
+ Hits         5365     5367    +2     
  Misses        769      769           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Comment on lines +5470 to +5474
/// The standard library's [`derive(Hash)`][derive@Hash] produces hashes by
/// individually hashing each field and combining the results. Instead, the
/// implementations of [`Hash::hash()`] and [`Hash::hash_slice()`] generated by
/// `derive(ByteHash)` convert the entirey of `self` to a byte slice and hashes
/// it in a single call to [`Hasher::write()`].
Copy link
Member

Choose a reason for hiding this comment

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

Maybe mention something about how this is often faster or easier to optimize or something to that effect? After all, that's the only reason you'd use this derive. Currently the only mention of optimization or performance in this doc comment is in the summary sentence.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

The "only mention" being in the summary sentence is fairly prominent positioning. I'm hesitant to over-promise here, because this derive isn't necessarily a performance slam dunk. For example, comparing two u64s for equality is likely to optimize better than casting them to slices of dynamic length and comparing them byte-by-byte. I'm really not sure where the inflection point is.

For that reason, I think the honest thing to do is to explain the mechanics, but not make specific promises about performance.

Comment on lines +5508 to +5511
/// The standard library's [`derive(Eq, PartialEq)`][derive@PartialEq] computes
/// equality by individually comparing each field. Instead, the implementation
/// of [`PartialEq::eq`] emitted by `derive(ByteHash)` converts the entirey of
/// `self` and `other` to byte slices and compares those slices for equality.
Copy link
Member

Choose a reason for hiding this comment

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

Same here re: mentioning performance

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

Successfully merging this pull request may close these issues.

3 participants