[swift-evolution] [Pitch] Requiring proactive overrides for default protocol implementations.

[Matthew Judge]

> On Apr 28, 2016, at 20:51, Erica Sadun via swift-evolution <swift-evolution at swift.org> 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 Module1
>> protocol 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.
> 

How does this match the first line in your "Handling Changes" table?

(from your table, for reference)
Original:  Some  member implemented in type
Change:  Protocol adds that member
Outcome:  Must add 'required' to type implementation or rename member to avoid conflict

>> 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.
> * It could be more easily confused when members are required by multiple protocols.
> 
> -- E
> 
> _______________________________________________
> 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/20160429/c684b127/attachment.html>