[swift-evolution] [Pitch] Requiring proactive overrides for default protocol implementations.
Andrew Bennett
cacoyi at gmail.com
Thu Apr 28 20:21:54 CDT 2016
Thanks for clarifying, my responses are inline.
On Fri, Apr 29, 2016 at 10:51 AM, Erica Sadun <erica at ericasadun.com> wrote:
>
> On Apr 28, 2016, at 6:44 PM, Andrew Bennett <cacoyi at gmail.com> wrote:
>
> Hey, what annotations would I have in this case:
>
> Module 1:
>
> Type AType { func foo() { ... } }
>
> Module 2:
>
> import Module1protocol A { func foo() {...default...} }extension AType: A {}
>
>
>
> No annotations. AType's implementation of foo is unrelated to its
> conformance, which is satisfied by its existing foo method.
>
Thanks, that resolves my misunderstanding. I thought there would need to be
an override or similar.
>
>
> Also, for your *alternatives* section:
>
> protocol A { func foo() {...default...} }Type AType: A {
> func A.foo() {...replacement...}
> }
>
>
> I actually prefer this alternative, I think it fixes many issues.
>
>
> Protocol default implementations do not yet exist.
>
> In this second, you're suggesting instead of doing "override required",
> you use a naming approach that ties the implementation the specific
> protocol. I'm not really won over by this approach:
>
> * It does clarify why the method is included
> * It does not clarify that the method overrides an existing implementation.
>
I agree with this, your `override` keyword would work well here.
* It could be more easily confused when members are required by multiple
> protocols.
>
I see this as a feature. I think this member should *only* implement it for
a single protocol.
If you have the same member in multiple protocols, then they potentially
(probably) do different things. They may want different implementations. If
the member is meant to represent the same thing, then it should be
extracted into a common protocol.
> -- E
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160429/45e3cb7a/attachment.html>
More information about the swift-evolution
mailing list