<html><head><style>
body {
font-family: "Helvetica Neue", Helvetica, Arial, sans-serif;
padding:1em;
margin:auto;
background:#fefefe;
}
h1, h2, h3, h4, h5, h6 {
font-weight: bold;
}
h1 {
color: #000000;
font-size: 28pt;
}
h2 {
border-bottom: 1px solid #CCCCCC;
color: #000000;
font-size: 24px;
}
h3 {
font-size: 18px;
}
h4 {
font-size: 16px;
}
h5 {
font-size: 14px;
}
h6 {
color: #777777;
background-color: inherit;
font-size: 14px;
}
hr {
height: 0.2em;
border: 0;
color: #CCCCCC;
background-color: #CCCCCC;
display: inherit;
}
p, blockquote, ul, ol, dl, li, table, pre {
margin: 15px 0;
}
a, a:visited {
color: #4183C4;
background-color: inherit;
text-decoration: none;
}
#message {
border-radius: 6px;
border: 1px solid #ccc;
display:block;
width:100%;
height:60px;
margin:6px 0px;
}
button, #ws {
font-size: 12 pt;
padding: 4px 6px;
border-radius: 5px;
border: 1px solid #bbb;
background-color: #eee;
}
code, pre, #ws, #message {
font-family: Monaco;
font-size: 10pt;
border-radius: 3px;
background-color: #F8F8F8;
color: inherit;
}
code {
border: 1px solid #EAEAEA;
margin: 0 2px;
padding: 0 5px;
}
pre {
border: 1px solid #CCCCCC;
overflow: auto;
padding: 4px 8px;
}
pre > code {
border: 0;
margin: 0;
padding: 0;
}
#ws { background-color: #f8f8f8; }
.bloop_markdown table {
border-collapse: collapse;
font-family: Helvetica, arial, freesans, clean, sans-serif;
color: rgb(51, 51, 51);
font-size: 15px; line-height: 25px;
padding: 0; }
.bloop_markdown table tr {
border-top: 1px solid #cccccc;
background-color: white;
margin: 0;
padding: 0; }
.bloop_markdown table tr:nth-child(2n) {
background-color: #f8f8f8; }
.bloop_markdown table tr th {
font-weight: bold;
border: 1px solid #cccccc;
margin: 0;
padding: 6px 13px; }
.bloop_markdown table tr td {
border: 1px solid #cccccc;
margin: 0;
padding: 6px 13px; }
.bloop_markdown table tr th :first-child, table tr td :first-child {
margin-top: 0; }
.bloop_markdown table tr th :last-child, table tr td :last-child {
margin-bottom: 0; }
.bloop_markdown blockquote{
border-left: 4px solid #dddddd;
padding: 0 15px;
color: #777777; }
blockquote > :first-child {
margin-top: 0; }
blockquote > :last-child {
margin-bottom: 0; }
code, pre, #ws, #message {
word-break: normal;
word-wrap: normal;
}
hr {
display: inherit;
}
.bloop_markdown :first-child {
-webkit-margin-before: 0;
}
code, pre, #ws, #message {
font-family: Menlo, Consolas, Liberation Mono, Courier, monospace;
}
.send { color:#77bb77; }
.server { color:#7799bb; }
.error { color:#AA0000; }</style></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class="bloop_markdown"><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 class="swift">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 class="bloop_original_html"><style>body{font-family:Helvetica,Arial;font-size:13px}</style><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;"><br></div> <br> <div id="bloop_sign_1474056889862798848" class="bloop_sign"><div style="font-family:helvetica,arial;font-size:13px">-- <br>Adrian Zubarev<br>Sent with Airmail</div></div> <br><p class="airmail_on">Am 16. September 2016 um 20:45:05, Vladimir.S via swift-evolution (<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>) schrieb:</p> <blockquote type="cite" class="clean_bq"><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>> http://davidbeck.co<br>> http://twitter.com/davbeck<br>> http://facebook.com/davbeck<br>><br>><br>><br>> _______________________________________________<br>> swift-evolution mailing list<br>> swift-evolution@swift.org<br>> https://lists.swift.org/mailman/listinfo/swift-evolution<br>><br>_______________________________________________<br>swift-evolution mailing list<br>swift-evolution@swift.org<br>https://lists.swift.org/mailman/listinfo/swift-evolution<br></div></div></span></blockquote></div><div class="bloop_markdown"><p></p></div></body></html>