<div style="white-space:pre-wrap">I feel like there's some parallels here between the design you're proposing (which is neat) and the discussion that's going on in two other threads about how almost any type can be converted to a String by default. There, we've heard deep dissatisfaction about that facility being invoked unintentionally.<br><br>I love the adage that code you don't write is code you don't have to debug. But I would add that code that's written for you because you chose not to write any yourself is code that someone else will have to debug.<br></div><br><div class="gmail_quote"><div dir="ltr">On Sun, May 29, 2016 at 01:58 Jon Shier <<a href="mailto:jon@jonshier.com">jon@jonshier.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><span style="white-space:pre-wrap"> </span>I’m sorry, I was misusing the 80/20 principle there, not making an argument that 80% of all types are trivially Equatable (though I would assert the number types that are trivially Equatable would be far greater than those that are not). I was merely stating that the rare cases in which a synthesized Equatable implementation might not be desired, even if possible, should not prevent this feature from existing and being as simple as possible. That is, some simple struct that contains only a few stored properties should be prevented from having a synthesized Equatable implementation because some representation of rational numbers may not be. Nor should I or the language have to use some special syntax or keyword to trigger such generation.</div><div style="word-wrap:break-word"><div><br></div><div><br></div><div>Jon Shier</div></div><div style="word-wrap:break-word"><div><br><div><blockquote type="cite"><div>On May 29, 2016, at 1:23 AM, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>> wrote:</div><br><div>That's quite the assertion you make. What's your evidence that 80% of the time an Equatable type is 'trivially' equatable? In stdlib? Foundation?<br><br>If you could demonstrate that it's really the case, I'd probably be inclined to support default synthesis of conformance to Equatable.<br><div class="gmail_quote"><div dir="ltr">On Sat, May 28, 2016 at 23:19 Jon Shier via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><blockquote type="cite"><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div>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></div><div style="word-wrap:break-word"><div><span style="white-space:pre-wrap"> </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><span style="white-space:pre-wrap"> </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><div style="word-wrap:break-word"><div><span style="white-space:pre-wrap"> </span></div><div><br></div><div><br></div><div><br></div><div>Jon Shier</div></div>_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</blockquote></div>
</div></blockquote></div><br></div></div></blockquote></div>