<div><br></div><div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote" dir="auto"><div>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.</div></div></blockquote><div dir="auto"><br></div><div dir="auto">I have similar concerns to Haravikk and I also understand the reasoning you outline. <br><br><div dir="auto">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).</div><div dir="auto"><br></div><div dir="auto">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&#39;t be a 1:1 mapping... likely seldom would it be in my experience.</div><div dir="auto"><br></div><div dir="auto">So at this time this feature would likely be of little utility to me in my code.</div><div dir="auto"><br></div><div dir="auto">With all that said... I want this feature +1 but with some futur things being omitted I won&#39;t gain much near term benefit form it.</div><div dir="auto"><br></div><div dir="auto">-Shawn</div><div dir="auto"><br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote" dir="auto"><div></div></div></blockquote></div></div>