If I understand the question correctly, Robert's asking whether the possibility that hashes might differ on every execution would causes issues if, upon deserializing, one stumbles upon a hash collision which did not occur with the original hashes. And I suppose the answer to that is...yes?
On Wed, Aug 16, 2017 at 6:16 PM, Tony Allevato via swift-evolution < swift-evolution@swift.org> wrote: > From what I can tell the hash values of elements in a Set don't come into > play during encoding/decoding: they're merely serialized as the sequence of > their elements. https://github.com/apple/swift/blob/ > 2e5817ebe15b8c2fc2459e08c1d462053cbb9a99/stdlib/public/core/ > Codable.swift#L4073-L4097 > > > On Wed, Aug 16, 2017 at 4:06 PM Robert Bennett via swift-evolution < > swift-evolution@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) >> >> On Aug 16, 2017, at 7:02 PM, Matthew Johnson via swift-evolution < >> swift-evolution@swift.org> wrote: >> >> >> On Aug 16, 2017, at 5:59 PM, Rudolf Adamkovic via swift-evolution < >> swift-evolution@swift.org> wrote: >> >> That's great. Thanks! >> >> >> Yes, excellent news! I am *really* looking forward to seeing this >> proposal make it into an Xcode release! >> >> >> R+ >> >> On 17 Aug 2017, at 00:46, John McCall <rjmcc...@apple.com> wrote: >> >> On Aug 16, 2017, at 6:35 PM, Rudolf Adamkovič via swift-evolution < >> swift-evolution@swift.org> wrote: >> >> This is fantastic news! Any chance of this landing in Swift 4.x instead >> of 5? >> >> >> It it likely to be available in 4.1, but not 4.0. >> >> John. >> >> >> R+ >> >> On 17 Aug 2017, at 00:29, Chris Lattner via swift-evolution < >> swift-evolution@swift.org> wrote: >> >> Proposal Link: https://github.com/apple/swift-evolution/blob/master/ >> proposals/0185-synthesize-equatable-hashable.md >> >> The review of SE-0185 “Synthesizing Equatable and Hashable conformance” >> ran from August 9…15, 2017. Feedback for the feature was glowingly >> positive, and the proposal is accepted. The core team discussed the >> concerns raised in the feedback thread for the proposal. Here are some >> rough notes (not intended to be exhaustive), but it is important to >> recognize that the proposal follows the design of the auto-synthesized >> Codable proposal, and that many of these same points were discussed when it >> came up: >> >> - The core team feels that adding compiler magic for this case is >> reasonable because it solves an important user need, and doesn’t preclude >> the introduction of a more general feature (e.g. like a macro system, or >> Rust's ‘deriving’ feature) in the future. When/if that feature is designed >> and built, the compiler magic can be replaced with standard library magic. >> >> - The hash value of a type is not intended to be stable across rebuilds >> or other changes to the code. It is ok to change if fields are reordered, >> the standard library changes the hash function, etc. Tony pointed this out >> on-thread, saying: The stdlib documentation for hashValue states "Hash >> values are not guaranteed to be equal across different executions of your >> program. Do not save hash values to use during a future execution.” >> >> - 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”. >> >> Many thanks to Tony Allevato for driving forward this proposal. The >> patch just needs final code review now - I think we’re all looking forward >> to this landing, congrats! >> >> Chris Lattner >> Review Manager >> >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org >> https://lists.swift.org/mailman/listinfo/swift-evolution >> >> >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org >> https://lists.swift.org/mailman/listinfo/swift-evolution >> >> >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org >> https://lists.swift.org/mailman/listinfo/swift-evolution >> >> >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org >> https://lists.swift.org/mailman/listinfo/swift-evolution >> >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org >> https://lists.swift.org/mailman/listinfo/swift-evolution >> > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution > >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution