<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><br><br>Sent from my iPad</div><div><br>On May 29, 2016, at 12:28 AM, Patrick Smith <<a href="mailto:pgwsmith@gmail.com">pgwsmith@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div><meta http-equiv="Content-Type" content="text/html charset=utf-8"><div class="">Yeah I don’t see a problem. It’s the same way that protocol extensions just work. Think of this automatic synthesis as a really flexible protocol extension:</div><div class=""><br class=""></div><div class="">extension Hashable where Members : Hashable {</div><div class=""> var hashValue : Int {</div><div class=""> return self.allMembers.reduce(^) // Or whatever combiner is best</div><div class=""> }</div><div class="">}</div></div></blockquote><div><br></div>Protocol extensions require you to declare conformance before your type receives their implementation and it must be identical for all do conforming types. <div><br></div><div>You should have to declare conformance to receive Equatable conformance and synthesis. IMO it makes sense to do that with 'deriving' which makes it clear that you are requesting synthesized rather than manual conformance.<div><div><br><blockquote type="cite"><div><div class=""><br class=""></div><br class=""><div><blockquote type="cite" class=""><div class="">On 29 May 2016, at 1:19 PM, Jon Shier via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><blockquote type="cite" class=""><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div class="">The problem with this is that it doesn’t differentiate between synthesized and manual conformance. You won’t get error messages you otherwise would when you intend to supply manual conformance. It is also less clear to a reader of the code that the default, compiler synthesized implementation is being generated.</div></div></blockquote></div><br class=""><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>I don’t think it’s reasonable to force the language down the path where developers don’t have to be familiar with its features in order to use them correctly. If types in Swift were to automatically gain Equatable and Hashable conformances whenever they were used by something that required them, that would be a core language feature, like type inference, that even junior developers in the language would need to know. Yet few (though not none) would insist that all types be manually declared, despite otherwise not knowing when our type inference goes wrong. It’s just a basic feature of the language that anyone using the language should know about, otherwise it can bite them in the ass when weird compiler errors start popping up. </div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>Frankly, IMO, this is an obvious case of 80/20 optimization. In the vast majority of cases where my types are trivially equatable, I should just be able to declare them as such and gain the compiler-synthesized ==. In the cases where that’s not possible, the compiler can emit an error. And in the cases where I want a custom == implementation I can provide it. Requiring a new keyword and not making this feature as simple as possible because the rare developer with a custom type who doesn’t want the synthesized == they just said they did by declaring Equatable conformance is an unnecessary defaulting to the rare case. </div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">Jon Shier</div></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class=""></div></blockquote></div></div></div></body></html>