<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Sep 13, 2017 at 2:47 PM, Vladimir.S via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">
<br></div></div>
As was noted in this thread, some people believe that protocol synthesizing its requirements by accessing type's fields is of a different kind than 'usual' protocol with default implementation.<br>
I belong to that camp. So, from my point of view, it is important to have 'deriving'-like marker for 'auto-senthesizeable' protocols as described above.</blockquote><div><br></div><div>This is a <a href="https://www.logicallyfallacious.com/tools/lp/Bo/LogicalFallacies/80/Distinction-Without-a-Difference">distinction without a difference</a>. Witness:</div><div><br></div><div>To the *author* of a type, there is no difference between a default implementation provided by a protocol extension, and one provided by compiler magic. In both cases the author simply conforms to the protocol and their type obtains the default method implementation which they may choose to override.</div><div><br></div><div>To the *maintainer* of a type, there is no difference between the two possible sources of a default implementation. They see that the type conforms, and that it does not implement the requirement, so they surmise a default implementation is in play, which they may choose to override.</div><div><br></div><div>To the *user* of a type, there is no difference either. They simply make use of the existing conformance, which means they can call the methods defined by the protocol.</div><div><br></div><div>The only interested party for whom the distinction is material, is the author of the protocol itself. And even there, the only difference is that with compiler magic the default implementation does not need to be written in a protocol extension.</div><div><br></div><div>***</div><div><br></div><div>Personally, I am *delighted* at where SE-0185 ended up. It makes simple cases simple, without changing what needs to be done for complex cases.</div><div><br></div><div>If we had been required to write an extra word like “deriving” or “auto”, that would make declarations for simple types more verbose and ugly, with no change to the complex case. It would be all cost and no benefit.</div><div><br></div><div>The way it is, though, we get both elegance and ease of use. And when we eventually add the “@transient” attribute, many of the currently-complex cases will become much simpler. We are in a good place, on the road to a better place, and the proposed modification in this thread would dig a hole in the pavement.</div><div><br></div><div>Nevin</div></div></div></div>