+1
I think the simple solution of if you provide either == or hashValue you have 
to provide both is the best approach. Good catch of this bug. 
-- Howard. 

> On 16 Dec 2017, at 6:24 am, Daniel Duan via swift-evolution 
> <swift-evolution@swift.org> wrote:
> 
> +1. The proposal wasn’t explicit enough to have either supported or be 
> against this IMO. It’s a sensible thing to spell out.
> 
> Daniel Duan
> Sent from my iPhone
> 
>> On Dec 15, 2017, at 9: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
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to