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 > <[email protected]> wrote: > > >> On Aug 16, 2017, at 5:59 PM, Rudolf Adamkovic via swift-evolution >> <[email protected]> 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 <[email protected]> wrote: >>> >>>> On Aug 16, 2017, at 6:35 PM, Rudolf Adamkovič via swift-evolution >>>> <[email protected]> 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 >>>>> <[email protected]> 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 >>>>> [email protected] >>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>> >>>> _______________________________________________ >>>> 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 > > _______________________________________________ > 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
