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

[Howard Lovatt]

I think that you should *always* have to write `override` when implementing
a protocol method, you can think of this as override an abstract
declaration. In particular I think the following should be enforced:

    protocol A { func a() }
    extension A { override func a() { ... } }
    struct AnA: A { override func a() { ... } }

    protocol B { func b() }
    struct AB: B { override func b() { ... } }

I think this change will work out well since it mimics what happened in
Java, originally the Java annotation `@Override` was used much like
`override` is currently used in Swift. However it was problematic and was
changed so that you always add the annotation, as shown above (in the
Swift context). One of the big advantages of this change is that the error
messages are much better (this was very noticeable in Java).

This proposal has come up before on swift-evolution, so it obviously has
some support.

On Thursday, 28 April 2016, Erica Sadun via swift-evolution <
swift-evolution at swift.org> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160428/8124e5b9/attachment.html>