<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Seems to me like a heavy weight solution to invent a special keyword that will be applicable to 2 protocols in the entire standard library.&nbsp;</div><div class=""><br class=""></div><div class="">If I am not mistaken, the Swift philosophy seems to be that Protocols carry the meaning, not how we apply them. So in this instance, something like the following might convey the meaning of both equality, and how the compiler should assist.</div><div class=""><br class=""></div><div class=""><div style="margin: 0px; line-height: normal; font-family: Menlo; color: rgb(187, 44, 162);" class=""><span style="font-variant-ligatures: no-common-ligatures" class="">public</span><span style="font-variant-ligatures: no-common-ligatures; color: #000000" class=""> </span><span style="font-variant-ligatures: no-common-ligatures" class="">protocol</span><span style="font-variant-ligatures: no-common-ligatures; color: #000000" class=""> Equatable {</span></div><div style="margin: 0px; line-height: normal; font-family: Menlo; color: rgb(0, 132, 0);" class=""><span style="font-variant-ligatures: no-common-ligatures; color: rgb(0, 0, 0);" class="">&nbsp; &nbsp;&nbsp;</span><span style="color: rgb(187, 44, 162); font-variant-ligatures: no-common-ligatures;" class="">@warn_unused_result</span></div><div style="margin: 0px; line-height: normal; font-family: Menlo;" class=""><span style="font-variant-ligatures: no-common-ligatures" class="">&nbsp; &nbsp; </span><span style="font-variant-ligatures: no-common-ligatures; color: #bb2ca2" class="">public</span><span style="font-variant-ligatures: no-common-ligatures" class=""> </span><span style="font-variant-ligatures: no-common-ligatures; color: #bb2ca2" class="">func</span><span style="font-variant-ligatures: no-common-ligatures" class=""> ==(lhs: </span><span style="font-variant-ligatures: no-common-ligatures; color: #703daa" class="">Self</span><span style="font-variant-ligatures: no-common-ligatures" class="">, rhs: </span><span style="font-variant-ligatures: no-common-ligatures; color: #703daa" class="">Self</span><span style="font-variant-ligatures: no-common-ligatures" class="">) -&gt; </span><span style="font-variant-ligatures: no-common-ligatures; color: #703daa" class="">Bool</span></div><div style="margin: 0px; line-height: normal; font-family: Menlo;" class=""><span style="font-variant-ligatures: no-common-ligatures" class="">}</span></div></div><div class=""><span style="font-variant-ligatures: no-common-ligatures" class=""><br class=""></span></div><div class=""><br class=""></div><div class=""><div class=""><div style="margin: 0px; line-height: normal; font-family: Menlo; color: rgb(0, 132, 0);" class=""><span style="font-variant-ligatures: no-common-ligatures" class="">/// Declaring conformance to this protocol results in the compiler</span></div><div style="margin: 0px; line-height: normal; font-family: Menlo; color: rgb(0, 132, 0);" class=""><span style="font-variant-ligatures: no-common-ligatures" class="">/// automatically generating a deep-equal between each members of</span></div><div style="margin: 0px; line-height: normal; font-family: Menlo; color: rgb(0, 132, 0);" class=""><span style="font-variant-ligatures: no-common-ligatures" class="">/// the conforming instances</span></div><div style="margin: 0px; line-height: normal; font-family: Menlo; color: rgb(187, 44, 162);" class=""><span style="font-variant-ligatures: no-common-ligatures;" class="">public</span><span style="font-variant-ligatures: no-common-ligatures; color: rgb(0, 0, 0);" class="">&nbsp;</span><span style="font-variant-ligatures: no-common-ligatures;" class="">protocol</span><span style="font-variant-ligatures: no-common-ligatures; color: rgb(0, 0, 0);" class="">&nbsp;AutoDeepEquatable : Equatable {</span></div><div style="margin: 0px; line-height: normal; font-family: Menlo;" class="">}</div></div><div class=""><span style="font-variant-ligatures: no-common-ligatures;" class=""><div class=""><div style="margin: 0px; line-height: normal; font-family: Menlo; color: rgb(0, 132, 0);" class=""><span style="font-variant-ligatures: no-common-ligatures;" class=""><br class=""></span></div><div style="margin: 0px; line-height: normal; font-family: Menlo; color: rgb(0, 132, 0);" class=""><span style="font-variant-ligatures: no-common-ligatures;" class="">/// Declaring conformance to this protocol results in the compiler</span></div><div style="margin: 0px; line-height: normal; font-family: Menlo; color: rgb(0, 132, 0);" class=""><span style="font-variant-ligatures: no-common-ligatures;" class="">/// automatically generating a shallow-equal between each&nbsp;</span>members&nbsp;</div><div style="margin: 0px; line-height: normal; font-family: Menlo; color: rgb(0, 132, 0);" class="">/// of the conforming instances</div><div style="margin: 0px; line-height: normal; font-family: Menlo; color: rgb(187, 44, 162);" class=""><span style="font-variant-ligatures: no-common-ligatures;" class="">public</span><span style="font-variant-ligatures: no-common-ligatures; color: rgb(0, 0, 0);" class="">&nbsp;</span><span style="font-variant-ligatures: no-common-ligatures;" class="">protocol</span><span style="font-variant-ligatures: no-common-ligatures; color: rgb(0, 0, 0);" class="">&nbsp;AutoShallowEquatable : Equatable {</span></div><div style="margin: 0px; line-height: normal; font-family: Menlo;" class="">}</div></div><div class=""><span style="font-variant-ligatures: no-common-ligatures;" class=""><br class=""></span></div><div class=""><span style="font-variant-ligatures: no-common-ligatures;" class=""><br class=""></span></div><div class=""><span style="font-variant-ligatures: no-common-ligatures;" class=""><br class=""></span></div></span></div></div><br class=""><div><blockquote type="cite" class=""><div class="">On May 30, 2016, at 9:04 PM, Michael Peternell via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">It seems that there are two groups here. 1) Group 1 wants Equatable (and others) be derived automatically unless specifically overridden: similar to auto-synthesis of properties in Objective-C. 2) The other group (Group 2) wants Equatable (and others) be derived explicitly using a `deriving` keyword (or something semantically equivalent). Unless I missed something, there were no voices for keeping the status quo, and not introducing any process to automatically derive these protocols.<br class=""><br class="">I think I chose an easy strategy when proposing the `deriving` keyword. Haskell is a mature language, and "copying" a feature from them is usually a safe choice. For each language feature, someone has to think through all the implications of it; this is usually far from trivial. I argue that if I take a feature from another language, someone has probably already thought about all the pros and cons of different solutions. This is just a plea for embracing precedent.<br class=""><br class="">There is one advantage of method 2 that (I think) hasn't been discussed so far: when you declare a type `S`, and an `Equatable` instance is automatically derived, there is no way to override that instance in another module. With method 1, there is also no way to request that an `Equatable` instance should *not* be generated. I think no one will vote for something like `struct S @notderiving(Equateble,Hashable) { ... }`.<br class=""><br class="">Also, a `deriving` keyword is less magical than just automatically deriving `Equatable` and `Hashable` instances. I think the language rules should be as simple as possible, by default. If you want any kind of special behavior, you have to ask for it: `deriving Equatable`, `@IBOutlet`, `@NSManaged`. Furthermore, I think it is good that the developer is aware that there is an "==" method somewhere, specifically for this new type. The compiler should not arbitrarily create methods, because someone may need them. Even if it is very likely that you will need them. Just like in a coffee house, you are asked if you want a coffee, even if you are visiting it every day. For example with Objective-C, I want each developer to be aware of the difference between a property and an iVar, and be aware of the connection between properties, methods, and key-value-coding. The complexities of the language shouldn't be hidden completely.<br class=""><br class="">Just my two cents..<br class=""><br class="">-Michael<br class=""><br class="">_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></div></blockquote></div><br class=""></body></html>