Thank you for driving this forward.
Equatability through conditional conformance has been discussed a lot, but in the end we didn't get very far.
As for implicit or explicit adoption of the default equatability I am undecided. If you have to opt in explicitly you will no longer get a compiler warning if you forget to write your custom implementation (if that is what you intended).
As for omitting properties from equating or hashing, I find this very important. I didn't count my equatable structs, but I think many would need a custom implementation, especially the more complex types.
I definitely want the option to include computed properties in the equality test. A common scenario would be: omit two stored properties, include one computed property instead.
It has also been suggested that property behaviors may be used for this.
I never followed the discussion on these, but here is a test balloon: let a property (stored or computed) return an optional Bool when compared to the same property of another instance. nil = don't care. The property can decide whether to use simple equality (if defined) or some struct type-specific equality. More flexible and saves two keywords.
I don't know if and when property behaviors are going to happen. Switching from attributes to property behaviors would be a thoroughly breaking change of course.
On May 25, 2016, at 9:04 PM, Tony Allevato wrote:
I was inspired to put together a draft proposal based on an older
discussion in the Universal Equality, Hashability, and Comparability thread