japaric / hash32 Goto Github PK

When depending on the hash32 create, but not the hash crate, I'm getting the following error when trying to derive Hash32:

error[E0463]: can't find crate for `hash32`                                                              
   --> src/mac.rs:299:40                                                                                 
    |                                                                                                    
299 | #[derive(Clone, Copy, Debug, Eq, Hash, Hash32, PartialEq)]                                         
    |                                        ^^^^^^ can't find crate                                     

If I also add a dependency on hash32, the error goes away and everything works as expected.

It's possible to implement hash32::Hasher as an extension of core::hash::Hasher, rather than a replacement:

pub trait Hasher: core::hash::Hasher {
    // This isn't the best name, but calling it `finish` would conflict with the method of `core::hash::Hasher`.
    fn finish32(&self) -> u32;
}

This would allow using the standard Hash type instead of needing a custom version, and also remove the need for a custom derive macro.

Obviously, this would be a breaking change. Even if everything else was kept the same, and a blanket impl of core::hash::Hasher for hash32::Hasher was used instead of modifying hash32::Hasher, that would break any crates which already implemented both.

I've made a draft implementation at https://github.com/Liamolucko/hash32/tree/use-std.

do you have a roadmap to releasing a v1.0.0? it would be cool if you could create the tickets for what you think is missing for v1.0.0 and assign them to a v1.0.0 milestone.

rationale: theoretically, one should only build on released software, so using 0.x pre-releases for production software isn't looked on too well. in the rust eco-system there are sadly a lot of crates which stay on 0.x for years but are heavily used. having a roadmap helps in understanding why a crate is not yet released as 1.x (or higher) and allows analysing the trade-offs (is it acceptable to use the crate in production even though these features are missing?).

furthermore, this would help with contributors: they know where work still needs to be done and they can offer their help focused on these topics.

specifically this seems to block the heapless crate from releasing an 1.0.0 release: rust-embedded/heapless#410 (comment)

with over 9 million downloads the hash32 crate is heavily used in the (embedded) rust ecosystem (see also the dependent crates, primarily through heapless) and having a stable release would be beneficial for all of them.

this crate seems to be very stable (no open issues, only one open PR, no commits since a year), indicating that it'd be a good candidate for an 1.0.0 release (either just re-release the last release as 1.0.0 or optionally include some cleanups along with it if needed).

I'm getting the following error when trying to derive Hash32 for an enum:

error: proc-macro derive panicked
   --> src/mac.rs:464:40
    |
464 | #[derive(Clone, Copy, Debug, Eq, Hash, Hash32, PartialEq)]
    |                                        ^^^^^^
    |
    = help: message: #[derive(Hash)] doesn't currently support `enum` and `union`

It would be very useful to have support for enums!

It seems that tuples containing only types that implement hash32::Hash don't implement Hash themselves:

the trait bound `(u16, u16): hash32::Hash` is not satisfied
  --> examples/dw1000_rx_tx.rs:41:27
   |
41 |     let mut known_nodes = FnvIndexSet::<_, heapless::consts::U64>::new();
   |                           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the trait `hash32::Hash` is not implemented for `(u16, u16)`
   |
   = note: required by `<heapless::indexset::IndexSet<T, N, hash32::BuildHasherDefault<S>>>::new`

It would be very useful to have this.