<div dir="ltr"><div><div>I wrote a proposal few weeks ago about "Complete Composition Model" in Swift, but still not finish (too many details)...</div><div> </div><div>In my proposal, i thought about the problem in this topic. However after thinking more generally, I found it best to solve in other direction:</div><div><br></div><div>- Every time one default protocol implementations is provide, the generated Header will include de "default" at beginner.</div><div>-- No source code change, the change is just for generated header. For Frameworks and libs, will apear em the "final generated header" of course. But for changes in our own module, will apear on xcode generated header, auto complete, detail tab, changes in color code, etc...</div><div><br></div><div>The ideia is provide a way to "see" more easily if a method has a default implementation, but does not change de code itself because this implementation can be made any time by someone, without break anything. </div><div><br></div><div>- Every time we "re implement" one default protocol implementation for other module with already have this "default" keyword, we need to provide a "implements" (or require) keyword to avoid a compiler warning.</div><div>-- Do not put a keyword to tell if you are implementing a protocol requirement is not exactly a error, but can be considered if you previously know about default implementation. No keyword is needed if no default implementations is provided, but can be used for clarify the intention.</div><div><br></div><div>- For or own module, xcode / auto-complete, detail tab, color code, etc... can tel you about the "has default implementation" without the warning.</div><div><br></div><div>At end of the day, there no need to any noise to tell something about default implementation, just a little help.</div><div><br></div><div>If we make "everything explicit", inference type will be abolished. Sometimes we can count on to develop "look the metadatas/interfaces"</div></div><div><br></div><div>If someone wants I can post the proposal I have written tomorrow.<br></div></div><br><div class="gmail_quote"><div dir="ltr">Em qui, 28 de abr de 2016 às 02:08, Charles Srstka via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> escreveu:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>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.</div></div><div style="word-wrap:break-word"><div><br></div><div>Charles</div></div><div style="word-wrap:break-word"><br><div><blockquote type="cite"><div>On Apr 27, 2016, at 8:26 PM, Howard Lovatt via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br><div><div dir="ltr">@Tod,<div><br></div><div>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.:</div><div><br></div><div> protocol ViewObserver { </div><div> func append(observer observer: Observer) </div><div> func remove(observer observer: Observer)</div><div> func removeAll()</div><div> }</div><div> struct AViewObserver: ViewObserver {</div><div> func apend(observer observer: Observer) {</div><div> ...</div><div> }</div><div> func remove(observer observer: Observer) {</div><div> ...</div><div> }</div><div> func removeAll() {</div><div> ...</div><div> }</div><div> }<br></div><div><br></div><div>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` :(.</div><div><br></div></div><div class="gmail_extra"><br clear="all"><div><div> -- Howard.<br></div></div>
<br><div class="gmail_quote">On 28 April 2016 at 11:17, Tod Cunningham <span dir="ltr"><<a href="mailto:tcunningham@vectorform.com" target="_blank">tcunningham@vectorform.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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.<br>
<br>
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):<br>
func (protocolname1, protocolname2) commonmethod() -> Void { .. the implementation.. }<br>
<br>
- Tod Cunningham<br>
________________________________________<br>
From: <a href="mailto:swift-evolution-bounces@swift.org" target="_blank">swift-evolution-bounces@swift.org</a> <<a href="mailto:swift-evolution-bounces@swift.org" target="_blank">swift-evolution-bounces@swift.org</a>> on behalf of Josh Parmenter via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>><br>
Sent: Wednesday, April 27, 2016 8:27 PM<br>
To: Howard Lovatt<br>
Cc: swift-evolution<br>
Subject: Re: [swift-evolution] [Pitch] Requiring proactive overrides for default protocol implementations.<br>
<br>
On Apr 27, 2016, at 17:23, Howard Lovatt via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><mailto:<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>>> wrote:<br>
<br>
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:<br>
<br>
protocol A { func a() }<br>
extension A { override func a() { ... } }<br>
struct AnA: A { override func a() { ... } }<br>
<br>
protocol B { func b() }<br>
struct AB: B { override func b() { ... } }<br>
<br>
<br>
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.<br>
Best<br>
Josh<br>
<br>
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).<br>
<br>
This proposal has come up before on swift-evolution, so it obviously has some support.<br>
<br>
On Thursday, 28 April 2016, Erica Sadun via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><mailto:<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>>> wrote:<br>
>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.<br>
<br>
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.<br>
<br>
I envision this as using the same `override` keyword that's used in class based inheritance but extend it to protocol inheritance:<br>
<br>
protocol A {<br>
func foo()<br>
}<br>
<br>
extension A {<br>
func foo() { .. default implementation ... }<br>
}<br>
<br>
type B: A {<br>
<br>
override required func foo () { ... overrides implementation ... }<br>
}<br>
<br>
<br>
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:<br>
<br>
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?<br>
<br>
type B: A, C {<br>
override required func foo() { A.foo(); C.foo() }<br>
}<br>
<br>
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.<br>
<br>
type B: A {<br>
override required func foo() { A.foo(); ... my custom behavior ... }<br>
}<br>
<br>
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.<br>
<br>
- E<br>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><mailto:<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a></blockquote></div><br></div>
_______________________________________________<br>swift-evolution mailing list<br><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br></div></blockquote></div><br></div>_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</blockquote></div>