[swift-evolution] [Proposal] clarification around protocol implementation and protocol extensions

[Xiaodi Wu]

This draft proposes something that's been discussed on this list several
times over the past few years, but now with a different spelling. However,
previous objections never centered around the spelling.

As discussed in previous threads on this topic, any such required keyword
breaks retroactive conformance. That is, if I want to conform someone
else's type to my protocol, I must edit that person's code if your idea is
accepted.

In so doing, this idea rejects an important (essential, IMO) mental model
of what protocol conformance entails. Specifically, I conform a type T to a
protocol P when I discover, having already implemented T, that it fulfills
the semantic and syntactic requirements of P. Unlike subclassing, I'm not
setting out with the intention of making a type T that conforms to P;
rather, I discover this fact to my great delight after implementation of T.
The analogy to subclassing is therefore inaccurate. Notionally, one always
inherits from a superclass first, then overrides.

This is no mere theoretical notion. It is a Swift idiom to state
conformance to protocols in an extension. Sometimes, the type will already
implement some but not all of the protocol's requirements outside that
extension because it is essential to the raison d'être of the type, and
only the balance of the requirements would then be implemented in the
extension that states conformance. It would be exceedingly unfortunate to
forbid this pattern, which is both elegant and expressive, but OTOH it
would be strange to have a method declare that it fulfills a requirement of
a protocol to which, lexically, it had not yet been conformed.

Lastly, it makes a very common task, that of conforming to a protocol,
syntactically heavy. This is exacerbated when you consider that the scheme
outlined here has the greatest benefit only when conformance to one
protocol is concerned. When conforming to more than one protocol, a similar
level of compiler help can only be obtained if you allow annotations as to
which protocol's requirement is being fulfilled. To implement this
additional syntax would be ludicrously heavy, but to ignore the issue would
be failing to consider one major aspect of protocols: composability (as
opposed to single inheritance). Again here, this is a critical difference
from subclassing that makes adapting "override" (regardless of whether you
choose a novel spelling) ineffectual.

Previous discussions on this topic have agreed that the developer
experience of conforming a type to a protocol can be greatly improved, but
the consensus has been that requiring a keyword to indicate protocol
requirements is not the way to go about it. I too would love to see
progress made on this issue, but having been previously an advocate for a
solution similar to yours, the views of some very wise people have changed
my thinking.
On Fri, Feb 17, 2017 at 21:29 David Waite via swift-evolution <
swift-evolution at swift.org> wrote:

> I wrote up the following draft proposal around attempting to clarify
> protocol implementation and protocol extensions, via annotating methods and
> properties meant to satisfy protocol requirements with additional keywords:
>
> "Types implementing protocols with optional features (either through
> default implementations on extensions, or optional methods on objective-C
> protocols) do not have a way to detect either local typos or later upstream
> changes to the protocol  method signatures will result in behavioral
> changes. This proposal attempts to rectify that in a manner similar
> to override on subclassed types."
>
> I’d appreciate feedback from the list! This is very much a first draft,
> likely filled with tyops.
>
> https://gist.github.com/dwaite/5a10e759a0efd0d9d16e066db4291552
>
> -DW
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170218/c6c9d4fc/attachment.html>