SE-0185 is awesome, and brings the long-awaited ability for the compiler to
provide a default implementation of `==` and `hashValue` when you don't provide
one yourself. Doug and I were talking the other day and thought of a potential
pitfall: what should happen if you provide a manual implementation of `==`
without also manually writing your own `hashValue`? It's highly likely that the
default implementation of `hashValue` will be inconsistent with `==` and
therefore invalid in a situation like this:
struct Foo: Hashable {
// This property is "part of the value"
var involvedInEquality: Int
// This property isn't; maybe it's a cache or something like that
var notInvolvedInEquality: Int
static func ==(a: Foo, b: Foo) -> Bool {
return a.involvedInEquality == b.involvedInEquality
}
}
As currently implemented, the compiler will still give `Foo` the default
hashValue implementation, which will use both of `Foo`'s properties to compute
the hash, even though `==` only tests one. This could be potentially dangerous.
Should we suppress the default hashValue derivation when an explicit ==
implementation is provided?
-Joe
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
