[swift-evolution] Refining SE-0185: Should providing a custom == suppress the default hashValue?

[Matthew Johnson]

+1.  I think there is a reasonable general principle at work here: the semantics of the implementation of a refining protocol depend upon the semantics of the implementation of a refined protocol.  For this reason the compiler should not synthesize an implementation for a refining protocol unless it also synthesizes (and can therefore reason about) the implementation of the refined protocol.

> On Dec 15, 2017, at 11:58 AM, Joe Groff via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 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
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution