> 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] > <mailto:[email protected]>> wrote: > >>> On Aug 16, 2017, at 6:35 PM, Rudolf Adamkovič via swift-evolution >>> <[email protected] <mailto:[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] <mailto:[email protected]>> wrote: >>>> >>>> Proposal Link: >>>> https://github.com/apple/swift-evolution/blob/master/proposals/0185-synthesize-equatable-hashable.md >>>> >>>> <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] <mailto:[email protected]> >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>> >>> _______________________________________________ >>> swift-evolution mailing list >>> [email protected] <mailto:[email protected]> >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> <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
