-
Notifications
You must be signed in to change notification settings - Fork 107
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
base: v0.8.x
Are you sure you want to change the base?
Conversation
This edit brings the structure of these docs in line with that used for our other derives.
Codecov ReportAll modified and coverable lines are covered by tests ✅
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. |
/// 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()`]. |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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 u64
s 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.
/// 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. |
There was a problem hiding this comment.
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
This edit brings the structure of these docs in line with that used for our other derives.