<div dir="ltr">I am really glad this is happening, it will make implementing basic data types much nicer, and it is exactly the sort of feature that saves developers from having to waste time thinking about trivial rote boilerplate both when writing and when reading code—an excellent and welcome addition to the language.<br><div><br></div><div>As for Haravikk’s scenario of marking a type as Equatable to trigger an error so you remember to implement the protocol later, you can achieve the same goal by tagging it “MakeMeEquatable” instead. The compiler will give an error (because there is no such protocol) and then you can come back to fix it another time.</div><div><br></div><div>Nevin</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Aug 16, 2017 at 6:29 PM, Chris Lattner via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Proposal Link: <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0185-synthesize-equatable-hashable.md" rel="noreferrer" target="_blank">https://github.com/apple/<wbr>swift-evolution/blob/master/<wbr>proposals/0185-synthesize-<wbr>equatable-hashable.md</a><br>
<br>
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:<br>
<br>
- 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.<br>
<br>
- 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.”<br>
<br>
- 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”.<br>
<br>
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!<br>
<br>
Chris Lattner<br>
Review Manager<br>
<br>
<br>
______________________________<wbr>_________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br>
</blockquote></div><br></div>