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