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 > <[email protected]> wrote: > > >> On 17 Aug 2017, at 00:06, Robert Bennett via swift-evolution >> <[email protected]> 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 >> <[email protected]> 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 > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
