Closed omus closed 1 year ago
For an example see: https://github.com/invenia/Intervals.jl/pull/47
(That "close and comment" button is too close to "comment")
I think that there is a problem with including type parameters into the hash: It violates the requirement that elements with different hashes must not be considered equal. For example, if you define
@auto_hash_equals struct A{T} x::T end
then isequal(A(0), A(0.0))
is true
. Hence the hashes have to agree.
isequal(A(0), A(0.0))
istrue
. Hence the hashes have to agree.
A very good point. I cases where additional information is encoded within the type parameters and those types should not hash to be the same (like in the linked example) declaring a hash
method seems like a reasonable approach.
Probably the only thing to be done as part of this issue is to document that @auto_hash_equals
isn't a good fit for those scenarios.
This package was completely overhauled in https://github.com/JuliaServices/AutoHashEquals.jl/pull/32. The caller can now decide if type arguments should be considered or not. I made "not" the default for compatibility with existing clients.
Please submit a new issue or PR if you think there is more work to do.
For some types the parametric types (or values) should be included in the hash. Probably
@auto_hash_equals
should use thetypeof
a type when producing a hash?