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

[Erica Sadun]

> On Apr 27, 2016, at 12:39 PM, Vladimir.S <svabox at gmail.com> wrote:
> 
> IMO very important questions and suggestions.
> 
> Firstly, wanted to ask about "required" keyword in your examples - do we expect to have it in meaning "implementing the protocol method" ? I'd like to have it very much.

I included it to mean “implementing a required protocol method”, providing a compile-time check that specifically addresses the same kind of issue as “near miss” detection. 

> * About the "override" keyword : +1 from me. We should be clear and explicit if we override method from default protocol implementation.
> Right now (as I understand) we have some mess when class and protocol has the same methods. For example :
> 
> protocol A {}
> 
> extension A {
>    func y() {print("Y in A")}
> }
> 
> class C:A {
>    func y() {
>        print("Y in C")
>    }
> }
> 
> var c : A = C()
> c.y() // what do you expect? "Y in A" is here. I expected "Y in C”

overriding a defaulted method without specific clarity of intent should raise a compiler warning. It is a likely spot where a developer may have acted without meaning to. Mandating override introduces another level of safety.

> Related topic 1&2 : IMO as soon as we have implementation in our protocols, and in this case they are 'like' classes, we need to be able to deal with these default methods implemented in protocols.
> 
> I.e. my point is if we allow protocols to be 'like' classes (to have implementations in methods), we need the tools(override,super.xxx) 'like' we have when inherit one class from another.
> 
> On 27.04.2016 20:10, Erica Sadun via swift-evolution wrote:
>> From the Swift Programming Language: /Methods on a subclass that override
>> the superclass’s implementation are marked with override—overriding a
>> method by accident, without override, is detected by the compiler as an
>> error. The compiler also detects methods with override that don’t actually
>> override any method in the superclass./
>> 
>> I would like to extend this cautious approach to protocols, forcing the
>> developer to deliberately override an implementation that’s inherited from
>> a protocol extension. This would prevent accidental overrides and force the
>> user to proactively choose to implement a version of a protocol member that
>> already exists in the protocol extension.
>> 
>> I envision this as using the same `override` keyword that’s used in class
>> based inheritance but extend it to protocol inheritance:
>> 
>> protocol A {
>>    func foo()
>> }
>> 
>> extension A {
>>    func foo() { .. default implementation … }
>> }
>> 
>> type B: A {
>> 
>>    override required func foo () { … overrides implementation … }
>> }
>> 
>> 
>> I’d also like to bring up two related topics, although they probably should
>> at some point move to their own thread if they have any legs:
>> 
>> Related topic 1: How should a consumer handle a situation where two
>> unrelated protocols both require the same member and offer different
>> default implementations. Can they specify which implementation to accept or
>> somehow run both?
>> 
>> type B: A, C {
>>    override required func foo() { A.foo(); C.foo() }
>> }
>> 
>> Related topic 2: How can a consumer “inherit” the behavior of the default
>> implementation (like calling super.foo() in classes) and then extend that
>> behavior further. This is a bit similar to how the initialization chaining
>> works. I’d like to be able to call A.foo() and then add custom follow-on
>> behavior rather than entirely replacing the behavior.
>> 
>> type B: A {
>>    override required func foo() { A.foo(); … my custom behavior … }
>> }
>> 
>> cc’ing in Jordan who suggested a new thread on this and Doug, who has
>> already expressed some objections so I want him to  have the opportunity to
>> bring that discussion here.
>> 
>> — E
>> 
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>