<div><br><div class="gmail_quote"><div dir="auto">On Tue, Sep 12, 2017 at 00:06 Gwendal Roué via swift-evolution <<a href="mailto:swift-evolution@swift.org">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><div><div class="gmail_quote"><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><br></div><div></div><blockquote type="cite"><div>This doesn't align with how Swift views the role of protocols, though. One of the criteria that the core team has said they look for in a protocol is "what generic algorithms would be written using this protocol?" AutoSynthesize doesn't satisfy that—there are no generic algorithms that you would write with AutoEquatable that differ from what you would write with Equatable.</div></blockquote><div><br></div></div><div style="word-wrap:break-word"><div>And so everybody has to swallow implicit and non-avoidable code synthesis and shut up?</div></div></blockquote><div><br></div><div>That's not what I said. I simply pointed out one of the barriers to getting a new protocol added to the language.</div><div><br></div><div>Code synthesis is explicitly opt-in and quite avoidable—you either don't conform to the protocol, or you conform to the protocol and provide your own implementation. What folks are differing on is whether there should have to be *two* explicit switches that you flip instead of one.</div></div></div></div></blockquote><div><br></div></div></div><div style="word-wrap:break-word"><div><div>No. One does not add a protocol conformance by whim. One adds a protocol conformance by need. So the conformance to the protocol is a *given* in our analysis of the consequence of code synthesis. You can not say "just don't adopt it".</div><div><br></div><div>As soon as I type the protocol name, I get synthesis. That's the reason why the synthesized code is implicit. The synthesis is explicitly written in the protocol documentation, if you want. But not in the programmer's code.</div><div><br></div><div>I did use "non-avoidable" badly, you're right: one can avoid it, by providing its custom implementation.</div><div><br></div><div>So the code synthesis out of a mere protocol adoption *is* implicit.</div></div></div><div style="word-wrap:break-word"><div><div><br></div><blockquote type="cite"><div><div class="gmail_quote"><div>Let's imagine a pie. The whole pie is the set of all Swift types. Some slice of that pie is the subset of those types that satisfy the conditions that allow one of our protocols to be synthesized. Now that slice of pie can be sliced again, into the subset of types where (1) the synthesized implementation is correct both in terms of strict value and of business logic, and (2) the subset where it is correct in terms of strict value but is not the right business logic because of something like transient data.</div></div></div></blockquote><div><br></div></div></div><div style="word-wrap:break-word"><div>Yes.</div><div></div></div><div style="word-wrap:break-word"><div><br><blockquote type="cite"><div><div class="gmail_quote"><div>What we have to consider is, how large is slice (2) relative to the whole pie, *and* what is the likelihood that developers are going to mistakenly conform to the protocol without providing their own implementation, *and* is the added complexity worth protecting against this case?</div></div></div></blockquote><div><br></div></div></div><div style="word-wrap:break-word"><div><div>That's quite a difficult job: do you think you can evaluate this likelihood?</div><div><br></div><div>Explicit synthesis has big advantage: it avoids this question entirely.</div><div><br></div><div>Remember that the main problem with slide (2) is that developers can not *learn* to avoid it.</div><div><br></div><div>For each type is slide (2) there is a probability that it comes into existence with a forgotten explicit protocol adoption. And this probability will not go down as people learn Swift and discover the existence of slide (2). Why? because this probability is driven by unavoidable human behaviors:</div><div>- developer doesn't see the problem (a programmer mistake)</div><div>- the developper plans to add explicit conformance later and happens to forget (carelessness)</div><div>- a developper extends an existing type with a transient property, and doesn't add the explicit protocol conformance that has become required.</div><div><br></div><div>Case 2 and 3 bite even experienced developers. And they can't be improved by learning.</div><div><br></div><div>Looks like the problem is better defined as an ergonomics issue, now.</div></div></div><div style="word-wrap:break-word"><div><br><blockquote type="cite"><div><div class="gmail_quote"><div>If someone can show me something that points to accidental synthesized implementations being a significant barrier to smooth development in Swift, I'm more than happy to consider that evidence. But right now, this all seems hypothetical ("I'm worried that...") and what's being proposed is adding complexity to the language (an entirely new axis of protocol conformance) that would (1) solve a problem that may not exist to any great degree, and (2) does not address the fact that if that problem does indeed exist, then the same problem just as likely exists with certain non-synthesized default implementations.</div></div></div></blockquote><br></div></div><div style="word-wrap:break-word"><div></div><div>There is this sample code by Thorsten Seitz with a cached property which is quite simple and clear : <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170911/039684.html" target="_blank">https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170911/039684.html</a></div><div><br></div><div>This is the sample code that had me enter the "worried" camp.</div></div></blockquote><div dir="auto"><br></div><div dir="auto">Sorry, I fail to see what the problem is in that example. A method was invoked that changed a stored property of one instance. Therefore, it’s no longer equal to the other instance. If you want a custom notion of equality, you should implement it yourself. In the absence of such, the _default_ notion of equality is pretty clear.</div><div dir="auto"><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></div></div><div style="word-wrap:break-word"><div><div style="margin:0px;font-size:14px;line-height:normal;font-family:'Helvetica Neue';color:rgba(0,0,0,0.85098)"><br></div></div><div>Gwendal</div><div><br></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>