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

[Matthew Judge]

I believe the following idea was brought up on the list the last time this topic came up, but I think it has a number of advantages and gets rid of the need for a 'required' keyword completely. I have reservations on the 'override' keyword as well, but the following idea would not preclude adding the 'override' keyword.

If an extension adds protocol conformance, only methods implementing the protocol are allowed in the body.  All methods from the protocol do not need to be implemented in the extension, so long as the type conforms overall.

struct Foo {
   func a() {}
}

protocol A {
   func a()
}
protocol B {
   func b()
}
protocol C {} 


extension Foo: A { } // retroactive modeling, no error

extension Foo: B {
   func b() {} // compiles, but "near miss" would not
}

extension Foo: C {
   func d() {} // error, d() not part of protocol C
}

Advantages:
- Clarifies intent... If you are implementing a method in an extension that declares a protocol conformance, it has to satisfy that one of that protocol's requirements
- Eliminates "near-miss" mistakes when implementing a function in an extension that declares protocol conformance, even in protocol has a default implementation (it would be an error to implement the non-matching-but-almost func)
- Fully supports retroactive modeling
- No new keywords required

Disadvantages:
- Source breaking change for any code that currently declares protocol conformance in an extension and implements an unrelated method
- Potential inconsistency with base type declaration (does this rule apply only to extensions or the initial declaration of the type?)
- Does not stop you from accidentally writing a implementation for a method that already has a default implementation in the protocol (though nothing here precludes the addition of adding 'override' as well)

Effectively, the only change required to current code would be to modify the above implementation of:

extension Foo: C {
   func d() {}
}

To read:

extension Foo: C {}
extension Foo {
   func d() {}
}

On Apr 29, 2016, at 11:44, Stephen Canon via swift-evolution <swift-evolution at swift.org> wrote:

>> On Apr 29, 2016, at 10:38 AM, Xiaodi Wu via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> I'd be keenly interested in something that would improve the experience of conforming a type to a protocol. I think others would as well. A sufficiently sophisticated solution would:
>> 
>> * catch unintentional typos that cause required functions to be incorrectly named
>> * show, ideally prospectively, which required functions have default implementations
>> * clarify (and this is obviously a cherry-on-top scenario) what protocol requirements any particular function helps to satisfy as well as which combination of implementations is used to synthesize a default implementation of another function (e.g. <= synthesized from < and ==; this would help to determine whether it might be more efficient to roll your own override)
>> * support all retroactive modeling scenarios currently supported
>> 
>> I tried to propose a keyword-based solution (less sophisticated than yours) a while back, and I've been convinced that the drawbacks in terms of decreased expressiveness in retroactive modeling might be insurmountable. Perhaps it would be worthwhile exploring improvements in tooling and documentation (including annotation of the code itself) in order to address some of these areas?
> 
> Yeah, I think this is something that tooling / editors could really help with.  I would love it if when I typed:
> 
>   struct Foo: Bar
> 
> or
> 
>   extension Foo: Bar
> 
> a skeleton with the missing Bar APIs was auto-generated for me to fill in.  This would make it much easier to get conformances right, and require less typing instead of more.
> 
> – Steve
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution