I would prefer the “override” only apply to methods that already had default protocol implementations, because then it could help avoid the mistake of overriding a default implementation that you didn’t realize was there, thinking that this was a method that you needed to supply.
Charles > On Apr 27, 2016, at 8:26 PM, Howard Lovatt via swift-evolution > <[email protected]> wrote: > > @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 <[email protected] > <mailto:[email protected]>> 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: [email protected] > <mailto:[email protected]> <[email protected] > <mailto:[email protected]>> on behalf of Josh Parmenter via > swift-evolution <[email protected] <mailto:[email protected]>> > 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 > <[email protected] > <mailto:[email protected]><mailto:[email protected] > <mailto:[email protected]>>> 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 > <[email protected] > <mailto:[email protected]><mailto:[email protected] > <mailto:[email protected]>>> 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 > [email protected] > <mailto:[email protected]><mailto:[email protected] > <mailto:[email protected]>> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution> > _______________________________________________ > swift-evolution mailing list > [email protected] <mailto:[email protected]> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution> > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
