+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@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@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
