<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Sep 12, 2017, at 11:00 AM, Xiaodi Wu via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><div class=""><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div class="gmail_quote"><div dir="auto" class=""><br class=""></div><div dir="auto" class="">Suppose instead this were about a protocol named Fooable and a requirement called foo() that has a default implementation. Everything you just talked about would apply equally. Am I to understand that you are opposed to default implementations in general? If so, then that’s got nothing to do with synthesized Equatable conformance. If not, then you’ll have to justify why.</div></div></div></div></blockquote><br class=""></div><div>First - I can go either way on this issue, since proper traits/mixins and hygienic macros both appear to be strong influencers which will drive evolution in ways we cannot evaluate yet.</div><div><br class=""></div><div>In my opinion, the difference between most protocol default implementations and Equatable/Hashable is that most protocol default implementations are based on the contract of the protocol itself. I can understand that Sequence#contains works by default because a Sequence implementation has a required makeIterator() function that meet the Sequence contract (and returns an Iterator that meets the iterator contract).</div><div><br class=""></div><div>There is nothing in the Equatable contract saying "two instances of a type are considered Equatable for value types when all the properties on the type are Equatable and compare as being equal." That is a behavioral assumption made by the default implementation.</div><div><br class=""></div><div>The current usage of traits in swift (in my experience) can be a bit deficient in that there is an assumption of a single behavior. For example - I might be able to default quite a bit of a view's delegate if I was willing to make assumptions, such as each row being a fixed size with a fixed (set of) views. But this is inappropriate as a default behavior for all table view delegates.</div><div><br class=""></div><div>We also have the disadvantage that we haven't solved the problem of indicating a method is meant to implement a protocol, so typos and incorrect function signatures can result in the wrong behavior at runtime.</div><div><br class=""></div><div>-DW</div></body></html>