We've had this discussion on the list multiple times already. The gist of the difficulty here is that most proposals for a mandatory keyword don't permit retroactive modeling, so it's a no-go. On the other hand, the core team seems to take a dim view to optional syntax, since that's more in the ballpark of linters.<br><br>I really don't see anything new here that we haven't already discussed at length...<br><br><br><div class="gmail_quote"><div dir="ltr">On Fri, Sep 16, 2016 at 15:25 Adrian Zubarev via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<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><p>I don’t really like the idea of <code>override(ProtocolName)</code>, but I’d support the single <code>override</code> here. On value types it’s easier to recognize the member of a protocol which had a default implementation.</p>
<p>I don’t feel like adding <code>override</code> to all members that replaces some default implementation will break anything. Furthermore, I’d love to see the addition where we could call the default implementation.</p>
<p>Here is some bikeshedding:</p>
<pre><code>protocol A {}
extension A {
func foo() { .. }
}
protocol B : A {}
extension B {
// overriding default implementation from an other one!?
override func foo() {
// call default implementation of A
default.foo()
}
}
struct C : A {
// overriding some default implementation
override func foo() {
// call default implementation
default.foo()
}
}
struct D : B {
// overriding some default implementation
override func foo() {
// call default implementation B
// which will also call default implementation of A
default.foo()
}
}
</code></pre>
<p></p></div><div></div></div><div style="word-wrap:break-word"><div><div style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto"><br></div> <br> <div><div style="font-family:helvetica,arial;font-size:13px">-- <br>Adrian Zubarev<br>Sent with Airmail</div></div></div></div><div style="word-wrap:break-word"><div> <br><p>Am 16. September 2016 um 20:45:05, Vladimir.S via swift-evolution (<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>) schrieb:</p> <blockquote type="cite"><span><div><div></div><div>David, thank you for a real-word example when such feature will be very <br>useful and can protect from hard-to-find bugs. IMO This shows that we <br>should find a solution for the problem as soon as possible.<br><br>Such or similar question was discussed already in an number of threads, for <br>example in "Requiring proactive overrides for default protocol <br>implementations." and in "Requiring special keyword to mark protocol <br>implementation methods", probably in other threads also.<br><br>The first is that `override` is not used in structs, so IMO it will be <br>alien here.<br>Second, if protocol has no default implementation for the method- would you <br>require the `override(Protocol)` also?<br><br>Then, in case you will not require a keyword when no default implementation <br>- you should think about retrospective adding of extension.<br><br>I.e. imagine, you have a source file, let's call it SomeClass.swift which <br>you can't or don't want to change(this could be some complex source from <br>3rd party, from github, or from other developer of your company). This file <br>compiles without problems. It contains:<br><br>public protocol Foo { func foo() }<br>public class Some: Foo { func foo() {...} }<br><br>You added SomeClass.swift to your project and in your My.swift you added <br>default implementation for Foo protocol:<br><br>extension Foo { func foo() {...} }<br><br>So, now, when you compile your project, there is default implementation for <br>foo() and class Some should contains `override(Foo)`, but you can't change <br>SomeClass.swift.<br><br><br>The only solution I see here, is if this `override(Foo)` will be optional, <br>and just express developer's intention, if he/she wants this. I.e. it is <br>not required, but if you specify it - compiler will check this intention.<br>But AFAIR unfortunately someone from core team mentioned that they don't <br>want such optional solution.<br><br>And, at the end, I do think the real reason of your problem is not that <br>protocol method has default implementation, but that <br>`viewController(with:properties:)` definition in `FooController` does not <br>say for compiler(and compiler does not check this) that this method was <br>defined *exactly* to confirm to protocol. I.e. you can't clearly express <br>your intention regarding why this method is here. Check this example:<br><br>Let's assume you defined protocol Foo in FooProto.swift file:<br><br>public protocol Foo { func foo() }<br><br>and have class `Some` conformed to Foo in SomeClass.swift:<br><br>public class Some : Foo { func foo() {...} }<br><br>it is clear *why* foo is here..<br><br>OK, now, let's assume you changed Foo protocol in the way, that <br>SomeClass.swift *still* compiles :<br><br>public protocol Foo { func bar() }<br>extension Foo {<br> func bar() {...}<br>}<br><br>Now, SomeClass.swift still compiles but it contains *wrong* intention that <br>foo() method is an implementation of protocol requirement. And this can <br>lead to bugs/unexpected behavior.<br><br><br>I think what we do need a way to clearly shows intention that we defined <br>some method *exactly* because the conformed protocol has it and to make <br>compiler check this.<br><br>My favorite solution is 'implements' keyword inside class/struct to <br>highlight that I defined this method as implementation for the protocol <br>requirement. IMO solves a big percent of discussed issues with just one <br>added keyword, that also will help with understanding the code when you <br>read it.<br><br>Other solution that was mentioned by (as I remember) member of core team is <br>treat class extension with protocol conformance as such intention, i.e. <br>when you say<br>extension Some: Foo {..}<br>compiler will understand this as all methods inside such extension must <br>'belongs' to the Foo protocol, i.e. if there is some method that does not <br>exist in Foo - it will raise an error. But in this case we need to require <br>that each protocol conformance will be declared as extension, not inline in <br>class definition. Personally I don't believe in this solution.<br><br><br>On 16.09.2016 18:29, David Beck via swift-evolution wrote:<br>> With the transition from Swift 2 -> 3 IБ─≥ve started running into one<br>> particular issue VERY often (although itБ─≥s not necessarily specific to the<br>> transition). If a protocol method is optional (either because it is an<br>> @objc optional or because it has a default implementation) there is a risk<br>> that the conformer will have a misspelled or slightly incorrectly typed<br>> implementation of the method. For instance:<br>><br>> protocolRouteDestinationViewController: class{<br>> staticfuncviewController(with url: URL, properties: [String:String]) -><br>> UIViewController?<br>> }<br>><br>> extensionRouteDestinationViewControllerwhereSelf: UIViewController {<br>> staticfuncviewController(with url: URL, properties: [String:String]) -><br>> UIViewController? {<br>> returnSelf.init()<br>> }<br>> }<br>><br>> classFooController: UIViewController, RouteDestinationViewController{<br>> staticfuncviewController(with url: URL, properties: [String:Any]) -><br>> UIViewController? {<br>> returnFooController(properties: properties)<br>> }<br>> }<br>><br>> Notice the issue there? Properties is supposed to be [String:String], but<br>> FooController uses [String:Any] (this is an exact issue I ran into after a<br>> small refactor). When viewController(with:properties:) is called, it will<br>> use the default implementation instead of what the compiler sees as a<br>> completely different method. Over the betas the compiler has gotten better<br>> warnings about this, but is still not 100%.<br>><br>> Other cases of this issue are common with imported ObjC protocols that have<br>> different naming in Swift. In some cases an @objc name must be applied to<br>> ensure it is declared in a way that the protocol can see it.<br>><br>> We solve this problem with subclassing by requiring Б─°overrideБ─². If the<br>> override keyword is present but the superclass doesnБ─≥t have a matching<br>> method, the compiler warns us about it. Similarly if the superclass<br>> implements the same method and the subclass doesnБ─≥t include override, we<br>> get a warning so that it is clear that you are overriding behavior.<br>><br>> For protocols, I donБ─≥t think a required keyword would be the best approach.<br>> ItБ─≥s a completely valid case that a type could conform to a protocol using<br>> existing methods, perhaps even from a different module. Further, a single<br>> method could satisfy multiple protocols, and be overriden from a<br>> superclass. What I would propose would be something like an optional<br>> override(<#protocol name#>). Something like the following:<br>><br>> override(RouteDestinationViewController) staticfuncviewController(with url:<br>> URL, properties: [String:Any]) -> UIViewController? {<br>> returnFooController(properties: properties)<br>> }<br>><br>> A method should be able to include multiple overrides (including a bare<br>> override to indicate that it is overriding a class method).<br>><br>> Thoughts? Are you seeing similar issues?<br>><br>> *David Beck*<br>> <a href="http://davidbeck.co" target="_blank">http://davidbeck.co</a><br>> <a href="http://twitter.com/davbeck" target="_blank">http://twitter.com/davbeck</a><br>> <a href="http://facebook.com/davbeck" target="_blank">http://facebook.com/davbeck</a><br>><br>><br>><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" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>><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" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br></div></div></span></blockquote></div></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>