cannot implement Hash except by IterBytes ?

[pnkfelix]

A strange problem: Let's say I want to implement the Hash trait myself, making use of the hash functions of my substructure, instead of by defining/deriving IterBytes.

rustc rejects my attempts to do so, saying that it failed to find an implementation of IterBytes for the structure in question.

Just to double-check my work, I cut-and-pasted a renamed version of the Hash trait into my code, and checked that I could indeed implement that (which I can):

Test case:

enum AB<A,B> { Lft(A), Rgt(B) }

pub trait Hash2 {
    fn hash_keyed(&self, k0: u64, k1: u64) -> u64;

    #[inline]
    fn hash(&self) -> u64 { self.hash_keyed(0,0) }
}

#[cfg(not(workaround))]
impl<A:Hash, B:Hash> Hash for AB<A,B> {
    fn hash_keyed(&self, k0: u64, k1: u64) -> u64 {
        match self {
            &Lft(ref a) => a.hash_keyed(k0, k1),
            &Rgt(ref b) => b.hash_keyed(k0, k1),
        }
    }
}

#[cfg(workaround)]
impl<A:Hash2, B:Hash2> Hash2 for AB<A,B> {
    fn hash_keyed(&self, k0: u64, k1: u64) -> u64 {
        match self {
            &Lft(ref a) => a.hash_keyed(k0, k1),
            &Rgt(ref b) => b.hash_keyed(k0, k1),
        }
    }
}

fn main() {

}

Transcript:

% rustc --version
/Users/pnkfelix/opt/rust-dbg/bin/rustc 0.8-pre (dd5c737 2013-09-08 12:05:55 -0700)
host: x86_64-apple-darwin
% rustc --cfg workaround /tmp/foo.rs
warning: no debug symbols in executable (-arch x86_64)
% rustc /tmp/foo.rs
/tmp/foo.rs:11:0: 18:1 error: failed to find an implementation of trait std::to_bytes::IterBytes for AB<A,B>
/tmp/foo.rs:11 impl<A:Hash, B:Hash> Hash for AB<A,B> {
/tmp/foo.rs:12     fn hash_keyed(&self, k0: u64, k1: u64) -> u64 {
/tmp/foo.rs:13         match self {
/tmp/foo.rs:14             &Lft(ref a) => a.hash_keyed(k0, k1),
/tmp/foo.rs:15             &Rgt(ref b) => b.hash_keyed(k0, k1),
/tmp/foo.rs:16         }
               ...
% 

[pnkfelix]

Ah, the comment above the Hash trait actually says: "Note that this trait is likely to change somewhat as it is closely related to to_bytes::IterBytes and in almost all cases presently the two are ( and must be ) used together." (emphasis added).

Still, this limitation in how one implements Hash seems strange to me. (Even though I agree that it is usually better to just delegate the definition of hash to IterBytes, the developer should be free to implement Hash their own way if they want.)

[pnkfelix]

The reason for this limitation is apparent in the implementation, as pointed out to me on IRC:

(from hash.rs):

impl<A:IterBytes> Hash for A {
    ...
}

I remain curious as to whether we intend to uphold this limitation permanently, or figure out another approach for resolving this. (But just so I am entirely upfront: I have no objections if we resolve this by saying: "If you want to implement your own hash function, then you have to also implement your own hash table with which to couple it", which is a work-around one can use today if one so desires.)

[pnkfelix]

see also commentary on #8038

[emberian]

This is quite unfortunate. I think it will be solved by the coherence relaxations (coherence currently ignores type parameters, and is thus overzealous), though Hash/IterBytes probably need to be restructured.

[emberian]

cc @nikomatsakis

[gereeter]

With the new Hash system, IterBytes is gone and this is fixed, so this should be closed.