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

[Dave Abrahams]

on Fri Apr 29 2016, Matthew Judge <swift-evolution at swift.org> wrote:

> 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)

If you need d as an implementation detail of the C conformance, this
will get annoying.

> 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
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-- 
Dave