-
Notifications
You must be signed in to change notification settings - Fork 965
Do we actually need the Hash trait? #1689
Copy link
Copy link
Closed
Labels
1.0Issues and PRs required or helping to stabilize the APIIssues and PRs required or helping to stabilize the APIAPI breakThis PR requires a version bump for the next releaseThis PR requires a version bump for the next releaseC-hashesPRs modifying the hashes cratePRs modifying the hashes cratebrainstorm
Description
Looking at the current code the only things bounded by Hash are Hmac and merkle tree, both actually require RawHash. We should consider removing the trait and use minimalistic RawHash for those two.
Pros/cons:
- Importing a trait every time one has to work with hashes is quite annoying.
- Trait provides us with a way to enforce consistent interface for all types, but the same can be and is achieved by macros.
- Someone somewhere may finally come up with an interesting algorithm where the abstraction is actually useful.
- It's possible to have both inherent items and trait items with the same name and it'll work just fine. This clutters docs though and may confuse some people.
- We would like the arrays in trait be defined as
[u8; Self::LEN]but it is currently impossible because of Tracking Issue for complex generic constants:feature(generic_const_exprs)rust-lang/rust#76560 Not having the trait simplifies it. - Referring to
<$type as $crate::Hash>::Itemin macros is more robust than<$type>::Item(and we have a few of these) - Traits can't have
const fnso constructors aren't const. This is quite a big deal.
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
1.0Issues and PRs required or helping to stabilize the APIIssues and PRs required or helping to stabilize the APIAPI breakThis PR requires a version bump for the next releaseThis PR requires a version bump for the next releaseC-hashesPRs modifying the hashes cratePRs modifying the hashes cratebrainstorm