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

[Howard Lovatt]

@Tod,

This was a concern when Java changed the behaviour of `@Override`, but it
didn't pan out. Everyone, even those with reservations, grew to like the
new behaviour. I think the much improved error messages from the compiler
helped, e.g.:

    protocol ViewObserver {
        func append(observer observer: Observer)
        func remove(observer observer: Observer)
        func removeAll()
    }
    struct AViewObserver: ViewObserver {
        func apend(observer observer: Observer) {
            ...
        }
        func remove(observer observer: Observer) {
            ...
        }
        func removeAll() {
            ...
        }
    }

The only error you get at present with the above is that `AViewObserver`
does not conform to `ViewObserver`, it doesn't tell you why. With the
change the compiler would highlight that `apend` doesn't override `append`
:(.


  -- Howard.

On 28 April 2016 at 11:17, Tod Cunningham <tcunningham at vectorform.com>
wrote:

> I think it would be odd and confusing to always have to use override when
> implementing protocol methods (especially protocol methods without default
> implementations).   To me override is telling me that there is another
> implementation, and I am for lack of a better word overriding that
> implementation.   However, for a protocol w/o a default implementation,
> there is no implementation.  You aren’t overriding anything.  You are just
> conforming to a signature.  Now protocol’s with default implementations
> there could be a case made for using override.  Expect Swift current
> implementation doesn't really override the default implementation, as shown
> in my example.  The other issues would be if I am overriding  something, I
> would expect to be able to execute the default implementation from within
> my override.
>
> It might be nice to have some syntax that would identify the protocol that
> is being implemented at the point of the implementation. For example
> (although I don't like this syntax):
>    func (protocolname1, protocolname2) commonmethod() -> Void { .. the
> implementation.. }
>
> - Tod Cunningham
> ________________________________________
> From: swift-evolution-bounces at swift.org <swift-evolution-bounces at swift.org>
> on behalf of Josh Parmenter via swift-evolution <swift-evolution at swift.org
> >
> Sent: Wednesday, April 27, 2016 8:27 PM
> To: Howard Lovatt
> Cc: swift-evolution
> Subject: Re: [swift-evolution] [Pitch] Requiring proactive overrides for
> default protocol implementations.
>
> On Apr 27, 2016, at 17:23, Howard Lovatt via swift-evolution <
> swift-evolution at swift.org<mailto:swift-evolution at swift.org>> wrote:
>
> 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'm rather new to the list - but I would like to say that I agree with
> this. I think it gives clarity both to code readability, and for learning
> the language.
> Best
> Josh
>
> 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<mailto: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
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org<mailto: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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160428/849a926a/attachment.html>