Change:
/// Feeds a slice of this type into the given [`Hasher`]. /// <ins> /// This method is meant as a convenience, but its implementation is /// also explicitly left unspecified. It isn't guaranteed to be /// equivalent to repeated calls of [`hash`] and implementations of /// [`Hash`] should keep that in mind and call [`hash`] themselves /// if the slice isn't treated as a whole unit in the [`PartialEq`] /// implementation. /// /// For example, a [`VecDeque`] implementation might naïvely call /// [`as_slices`] and then [`hash_slice`] on each slice, but this /// is wrong since the two slices can change with a call to /// [`make_contiguous`] without affecting the [`PartialEq`] /// result. Since these slices aren't treated as singular /// units, and instead part of a larger deque, this method cannot /// be used. /// </ins> /// # Examples /// /// ```

Discussion:
Currently is implemented as . The question is: is it a requirement for all implementations? In other words, is is true, that for each hasher implementation, call must be equivalent to ? (assuming host is little-endian). Why is it important. Suppose, you want to implement very simple hasher with state updated like . If does not have requirement as above, hasher can be implemented by simply casting any operand to and avoiding dealing with unaligned/smaller than u64 integers:
I’m fairly sure there was a discussion about it before and we decided against doing any changes to the libstd impl. Don’t exactly remember the reason, though.
If any decision is made, I wish it would be stated in the documentation of trait.
employs a different implementation to achieve platform-independence.
I don't think there's any such requirement. The in the compiler does exactly what your example does.
I think I would be opposed to this requirement; it imposes a performance penalty for systems of the "wrong" endianness, since they would need to correct their endianness. The only requirement on should be that the same sequence of calls produces the same result, I think.
My spec request: given two byte slices and , is equivalent to ? This way, we could define all the non-slice methods as explicitly being transmutes, always.
removing until lets us know what to document here.
My personal take on this is that we should only guarantee that produces the same value for the exact same sequence of calls. This even applies to plain calls on byte slices: a is only guaranteed to produce the same result if the same sequence of calls are used with the same slice lengths*. For an example of where this could make a difference, consider from Abseil which hashes short slices by reading 0-16 bytes and padding anything not included in the length with zeroes or duplicates of the existing bytes.
Based on the libs team decision in , I'm going to close this issue. The answer to the question in the issue title is no: is not required to be equivalent to 4 calls of .
Was there any updates to the documentation of Hasher? I didn't see any in a quick scan of threads.
Yeah, it seems like the thread was closed because the original idea was decided to not be done, but I agree that it shouldn't be closed until documentation is .

cc who closed this since it shouldn't be closed. Opened to add docs for this, but think this issue should be kept open until we've finally decided on how to document this.