[swift-evolution] [Proposal] Explicit Synthetic Behaviour

[Nevin Brackett-Rozinsky]

On Wed, Sep 13, 2017 at 2:47 PM, Vladimir.S via swift-evolution <
swift-evolution at swift.org> wrote:
>
>
> 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.
> 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.


This is a distinction without a difference
<https://www.logicallyfallacious.com/tools/lp/Bo/LogicalFallacies/80/Distinction-Without-a-Difference>.
Witness:

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.

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.

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.

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.

***

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.

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.

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.

Nevin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170913/3006376e/attachment.html>