<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="">Le 7 sept. 2017 à 14:37, Matthew Johnson <<a href="mailto:matthew@anandabits.com" class="">matthew@anandabits.com</a>> a écrit :</div><br class="Apple-interchange-newline"><div class=""><span 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; float: none; display: inline !important;" class="">I don't understand what this has to do with synthesized Equatable. Wouldn't manually implemented Equatable have the same impact? The design of a DSL should be able to accommodate conformance to basic protocols without ambiguity.</span></div></blockquote></div><div class=""><br class=""></div>I'll explain you:<div class=""><br class=""><div class="">The problem with synthesized Equatable is that it adds an unwanted == operator that returns a Bool.</div><div class=""><br class=""></div><div class="">This operator is unwanted because it conflicts with the == operator defined by the DSL which does not return a Bool.</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>// Without synthesised Equatable</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>let r = (a == b) // the type defined by the DSL</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>// With synthesised Equatable</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>let r = (a == b) // ambiguous</div><div class=""><br class=""></div><div class="">This is the same kind of conflict that happen when a function is overloaded with two return types:</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>func f() -> Int { ... }</div><div class=""><div class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>func f() -> String { ... }</div></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>f() // ambiguous</div><div class=""><br class=""></div><div class="">Without the synthesized Equatable, the type would not have any == operator that returns a Bool, and thus no conflict with the == operator defined by the DSL (the one that returns an SQL expression, in our particular context).</div><div class=""><br class=""></div><div class="">I hope that I have explained how synthesized conformance may impact code by the mere fact that they define methods. I'm not talking about the correctness of the synthesized code. I'm talking about its mere existence.</div><div class=""><br class=""></div><div class=""><div><blockquote type="cite" class=""><div class="">We generally want as many types to be Equatable and Hashable as possible. Synthesized conformance means more types will have these conformance and that's a good thing in all cases (so long as the implementation is correct). </div></blockquote><div><br class=""></div>Sure, of course. I'm with you. I'm not talking against code synthesis. Again, I'm not talking about the correctness either.</div><div><br class=""></div><div>I'm talking about the consequences of implicit and non-avoidable synthesis. Exactly the theme of this thread, unless I'm totally mistaken.</div><div><div class=""><div class=""><br class=""></div></div></div></div><div class="">Gwendal Roué</div></div><div class=""><br class=""></div></body></html>