> My hunch is that structs and enums where such volatile data exists are the > exception, not the norm, when it comes to considering equality. This > proposal is very much intended to be useful syntactic sugar for the common > case while not preventing any existing behavior (providing your own > implementation) and alluding to future directions where the behavior can be > extended to other use cases. >
I have similar concerns to Haravikk and I also understand the reasoning you outline. Reviewing code of ours and thinking back in time to prior (pre-swift projects) I currently think that automatic synthesis by simple statement of adopting Equat/Hashable would only be possible for the simplest of data structs and classes. It is often that more (slightly) complex structs and classes have various bookkeeping, metadata, and/or caching properties that should not be considered in the synthesized code however theses object are maintained in data structures that depend on Equat/Hashable conformance. In other words I would have to write an implementation myself (despite a synthesized version could be done if a subset of properties could be excluded) or possibly I would adopt one of those protocols and mistakenly forget to write my own implementation because automatic synthesis kicks in causing a lurking problem (so hopefully be quickly discovered). Also for data structs/classes built to deal with data exchange, say with a server API using JSON, the resulting data objects that leverage the new codable stuff in Swift 4 will almost universally have things that would allow automatic synthesis of Equat/Hashable however equally universally the equality of two objects decoded would depend on a small subset of the properties contained in the object (say a server id and some number of additional scoping ids). So I doubt that simply using something that would opt-out elements from automatic coding would map directly to opt-out of automatic compatibility, it wouldn't be a 1:1 mapping... likely seldom would it be in my experience. So at this time this feature would likely be of little utility to me in my code. With all that said... I want this feature +1 but with some futur things being omitted I won't gain much near term benefit form it. -Shawn
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution