<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto">I would say it is an advanced use because it is an optimisation and in addition an optimisation that requires a lot of knowledge of the fields to be certain that a reduced hash is going to be good enough. <div><br></div><div>The optimisation doesn’t have a great history, for example in Java they used to hash only the 1st 6 characters of a string. However this was exploited in denial of service attacks that generated a vast number of strings with the same hash value, i.e same 1st 6 characters, that then overwhelmed the dictionary (map in Java) used in the web server software to store logins. </div><div><br></div><div>So it wouldn’t be something I would encourage people to do or even worse do by accident. <br><br><div id="AppleMailSignature">-- Howard.</div><div><br>On 16 Dec 2017, at 3:36 pm, Tony Allevato <<a href="mailto:tony.allevato@gmail.com">tony.allevato@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Fri, Dec 15, 2017 at 6:41 PM Howard Lovatt <<a href="mailto:howard.lovatt@gmail.com">howard.lovatt@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto">I think that is an advanced use, rather than a common use. I would prefer that to be something you manually code. </div></blockquote><div><br></div><div>But why? Why should implementing a subset of fields for hashValue require a developer to also manually implement == when the default synthesized version would be perfectly fine? The relationship between Equatable and Hashable does not go both ways.</div><div><br></div><div>In fact, requiring that they do so is *more* error prone because now they're being forced to implement something that the compiler would have otherwise generated for them.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><br><br><div id="m_1702168286999014836AppleMailSignature">-- Howard.</div></div><div dir="auto"><div><br>On 16 Dec 2017, at 7:08 am, Tony Allevato <<a href="mailto:tony.allevato@gmail.com" target="_blank">tony.allevato@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Fri, Dec 15, 2017 at 11:39 AM Howard Lovatt via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">+1<br>
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.<br>
-- Howard.<br></blockquote><div><br></div><div>That would be a significant usability hit to a common use case. There are times where a value is composed of N fields where N is large-ish, and equality is dependent on the values of all N fields but the hash value only needs to be "good enough" by considering some subset of those fields (to make computing it more efficient).</div><div><br></div><div>That still satisfies the related relationship between == and hashValue, but a user wanting to explicitly implement a more efficient hashValue should *not* necessarily be required to explicitly write the same == that would be synthesized for them in that case.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> On 16 Dec 2017, at 6:24 am, Daniel Duan via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br>
><br>
> +1. The proposal wasn’t explicit enough to have either supported or be against this IMO. It’s a sensible thing to spell out.<br>
><br>
> Daniel Duan<br>
> Sent from my iPhone<br>
><br>
>> On Dec 15, 2017, at 9:58 AM, Joe Groff via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br>
>><br>
>> 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:<br>
>><br>
>> struct Foo: Hashable {<br>
>> // This property is "part of the value"<br>
>> var involvedInEquality: Int<br>
>> // This property isn't; maybe it's a cache or something like that<br>
>> var notInvolvedInEquality: Int<br>
>><br>
>> static func ==(a: Foo, b: Foo) -> Bool {<br>
>> return a.involvedInEquality == b.involvedInEquality<br>
>> }<br>
>> }<br>
>><br>
>> 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?<br>
>><br>
>> -Joe<br>
>> _______________________________________________<br>
>> swift-evolution mailing list<br>
>> <a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
>> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
> _______________________________________________<br>
> swift-evolution mailing list<br>
> <a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</blockquote></div></div>
</div></blockquote></div></blockquote></div></div>
</div></blockquote></div></body></html>