> 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
