Proposal Link:

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

Reply via email to