That's great. Thanks! 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
