std::ops::Range does not implement std::hash::Hash

[ntninja]

Range should implement Hash if the value it holds implements Hash.

Something like:

impl<T> core::hash::Hash for core::ops::Range<T> where T: core::hash::Hash {
    fn hash<H>(&self, state: &mut H) where H: core::hash::Hasher {
        core::hash::Hash::hash(self.start, state);
        core::hash::Hash::hash(self.end, state);
    }
}

[ntninja]

The same goes for RangeStart, RangeEnd and RangeFull of course.

[durka]

Can we just derive it?

[ntninja]

If we'd derive it, then all type parameters would be required to implement Hash if IIRC.

[sfackler]

Yep, but that's the behavior we'd want anyway, yes?

[durka]

Yes. Not sure how you'd hash a range with unhashable endpoints.
On Jun 9, 2016 8:35 AM, "Steven Fackler" [email protected] wrote:

Yep, but that's the behavior we'd want anyway, yes?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#34170 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AAC3n-SZhTHSXx14WG6yVFG1NcikobLdks5qKAh-gaJpZM4Ixhqh
.

[ntninja]

@sfackler No, if the thing that the range is variant over is not hashable, then the Range itself shouldn't be hashable either. Doing #[derive(Hash)] would require the type parameter to always be hashable, which I don't see any reason for (besides the fact that it would break compatibility).

[sfackler]

@Alexander255 I don't believe that's how #[derive(Hash)] works - all it will do is generate a hash impl that looks identical to the one in your original post. I does not modify bounds on the struct definition itself.

[ntninja]

@sflacker You're right:
Example with manual impl: https://is.gd/Jj6KRL
Example with derive: https://is.gd/W4O8ai

I was under the strong impression that #[derive(Hash)] will abort the compilation, requiring you to bound the type parameters appropriately (but apparently it's smarter than that).

[ntninja]

@durka Thanks!