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

[Benjamin G]

On Fri, Dec 15, 2017 at 6:58 PM, 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?
>

I would agree with the other people saying automatic implementation of
Hashable should be all-or-nothing, but this makes me wonder : shouldn't
this "all-or-nothign" rule be the same for all the automatically
implemented protocol ? If no, then how would you know, just by looking at
the protocol, which function is "overridable" and which isn't ? I suppose
trying and having the compiler raise an error shouldn't be the only option.



>
> -Joe
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171215/87cd6e00/attachment.html>