Tracking Issue for `Hasher::{write_str, write_length_prefix}` (`feature(hasher_prefixfree_extras)`)

[scottmcm]

Feature gate: #![feature(hasher_prefixfree_extras)]

This is a tracking issue for the new provided methods on Hasher added to fix #94026

• write_str lets the hasher customize how it works with str, so it can use the b'\xFF' trick if it's byte-wise, or a different approach if it does chunked rounds.
• write_length_prefix gives an obvious choice when implementing Hash for collections (like VecDeque) which can't just use the slice hash, and allows the hasher to optimize how best to represent the length.

Public API

// core::hash

pub trait Hasher {
    // ... existing stuff ...
    fn write_length_prefix(&mut self, len: usize);
    fn write_str(&mut self, s: &str);
}

Steps / History

• Implementation: Add a dedicated length-prefixing method to Hasher #94598
• Final comment period (FCP)
• Stabilization PR

Unresolved Questions

• What should the write_str provided implementation be? It was added matching the previous impl Hash for str behaviour to get in without breaking hash checks (like the one in cargo), but that's not always prefix-free (it depends on the round strategy), so there's an argument that a different implementation would be better.

[tgross35]

Possible bikeshed: it was indirectly mentioned in passing here that this is the only std API that comes up when you search length. The rest all seem to use len

[hoxxep]

Author of the rapidhash crate here, I'm wondering how to go about pushing this towards stabilisation?

Being able to omit the separate 0xFF write call when hashing strings would be a helpful performance boost in block-based hashing algorithms that already reseed using the byte length on every .write(&[u8]) call. Thanks!

[ChrisDenton]

See the stabilization process docs: https://std-dev-guide.rust-lang.org/development/stabilization.html#stabilization-report. Essentially write a stabilization report detailing what is being stabalized and why.

I see one "unresolved question" in the OP. That will probably need to be resolved one way or another.