[swift-evolution] [Accepted] SE-0185 - Synthesizing Equatable and Hashable conformance

[Robert Bennett]

Chris mentions that the intent was to mimic a default implementation in a constrained protocol extension, with one extension per type that doesn’t define its own ==/hashValue 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.

> On Aug 17, 2017, at 4:12 AM, Haravikk via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
>> On 17 Aug 2017, at 00:06, Robert Bennett via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> 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) 
> 
> 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.
> 
>> On 16 Aug 2017, at 23:29, Chris Lattner via swift-evolution <swift-evolution at swift.org> wrote:
>> 
> 
>> The code synthesized is meant to feel like a default implementation that you’re getting for free from a (constrained) extension on the protocol.  This is why conformance to the protocol itself is all that is required, not something like “AutoEquatable”.  
> 
> 
> 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 not 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 not clearly defined, to create an implementation that by its very nature must give accurate results.
> 
> 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.
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170817/125784b7/attachment.html>