<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div></div><div><span style="background-color: rgba(255, 255, 255, 0);">Chris mentions that the intent was to mimic a default implementation in a constrained protocol extension, with one extension per type&nbsp;that doesn’t define its own ==/hashValue&nbsp;while conforming to Equatable/Hashable. Constrained extensions are allowed to use type information from the constraint, so I don’t think there is an issue here.</span></div><div><br>On Aug 17, 2017, at 4:12 AM, Haravikk via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>&gt; wrote:<br><br></div><blockquote type="cite"><div><meta http-equiv="Content-Type" content="text/html charset=utf-8"><br class=""><div><blockquote type="cite" class=""><div class="">On 17 Aug 2017, at 00:06, Robert Bennett via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="content-type" content="text/html; charset=utf-8" class=""><div dir="auto" class=""><div class=""></div><div class="">How do unstable hash values play with Codable? If you encode and save a Set, might you have problems interacting with it in the future? (This is more a Codable question than Hashable, but I figure I might as well ask here)&nbsp;</div></div></div></blockquote><br class=""></div><div>I'm not big on the specifics of Codable, but collections are usually a case where you need to be careful about how exactly you encode them; i.e- you usually only want to encode the length and the contents, not anything related to the way in which they are actually stored. This way it doesn't matter if the hashes change, as you recreate the Set like you're adding all the values for the first time; any collisions should then be resolved as normal (i.e- assigning into buckets of non-identical items with the same hash). Nothing in a Set should ever be overwritten on the basis of its hash alone. Otherwise, any code that requires a more stable hash value should be using something other than Hashable to generate it.</div><div><br class=""></div><div><blockquote type="cite" class="">On 16 Aug 2017, at 23:29, Chris Lattner via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; wrote:</blockquote><blockquote type="cite" class=""><br class=""></blockquote></div><div><blockquote type="cite" class="">The code synthesized is meant to feel like a default implementation that you’re getting for free from a (constrained) extension on the protocol. &nbsp;This is why conformance to the protocol itself is all that is required, not something like “AutoEquatable”. &nbsp;</blockquote></div><div><br class=""></div><div>I still strongly feel that treating this like a default implementation is a mistake, especially in the case of Equatable; we are literally talking here about a feature that introduces the potential to hide bugs, and it is <b class="">not</b>&nbsp;the same as a default implementation, not at all as it uses details of the concrete type, rather than merely what is defined within the protocol itself, you are talking here about using parts of a type that are <b class="">not</b>&nbsp;clearly defined, to create an implementation that by its very nature <b class="">must</b>&nbsp;give accurate results.</div><div><br class=""></div><div>I mean, the whole point of a protocol is to define what we as developers need to do in order to ensure correct behaviour; when we start talking about providing that behaviour automatically with behind the scenes magic that necessarily has to make assumptions about a type then you lose any ability to guarantee correctness. I feel so strongly that this is a mistake that I would rather never see this feature implemented than see it implemented in this way, and feel that this concern has been trivialised and ignored.</div></div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></body></html>