<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">If we really want to be overkill, we could use `required` for implementing an un-defaulted protocol requirement, `override` for implementing a defaulted protocol requirement, and `default` for implementing a protocol requirement in a protocol extension.<div class=""><br class=""></div><div class="">I think this might be more verbose than necessary, but I think it is at least worth exploring some subset of those keywords. They all reuse existing ones too, which is mostly a plus.</div><div class=""><br class=""></div><div class="">The biggest benefit I see from these is confidence that what you wrote satisfies your expectations. Just like `try` is required to document at the call-site that a method throws and like argument labels are required to document at the call-site the usage of each parameter, it's reasonable to require these keywords to document these expectations at the implementation-site. If you forget them, the compiler can easily remind you.</div><div class=""><br class=""></div><div class="">Requiring `override` and/or `required` would make it clear that you're actually implementing the protocol. It's too easily to make a typo and define a completely unrelated method. If the requirement is defaulted, you would never know until runtime weirdness. These keywords make protocol conformance less stringily typed.</div><div class=""><br class=""></div><div class="">I'm +1 on this idea in some form (but not necessarily what I suggested).</div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Aug 24, 2016, at 10:13 AM, Christopher Kornher via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="content-type" content="text/html; charset=utf-8" class=""><div dir="auto" class=""><div class="">Requiring "override" when anything overrides a method defined in a protocol extension should be added - structure and enumerated included, of course.</div><div class=""><br class=""></div><div class="">Protocol extensions added inheritance to structs and enums and this should be made explicit.</div><div class=""><br class="">Sent from my iPad</div><div class=""><br class="">On Aug 24, 2016, at 12:55 AM, Charles Srstka via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><blockquote type="cite" class="">On Aug 24, 2016, at 1:20 AM, Robert Widmann <<a href="mailto:devteam.codafi@gmail.com" class="">devteam.codafi@gmail.com</a>> wrote:<br class=""></blockquote><div class=""><blockquote type="cite" class="">2016/08/23 20:52、Charles Srstka <<a href="mailto:cocoadev@charlessoft.com" class="">cocoadev@charlessoft.com</a>> のメッセージ:<br class=""><div class=""><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div class=""><div class=""><div class=""><div class=""><br class=""></div><blockquote type="cite" class=""><div class=""><blockquote type="cite" class="">On Aug 23, 2016, at 10:34 PM, Robert Widmann <<a href="mailto:devteam.codafi@gmail.com" class="">devteam.codafi@gmail.com</a>> wrote:<br class=""></blockquote><div class=""><blockquote type="cite" class=""><br class="Apple-interchange-newline"><div class=""><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">2016/08/23 15:29、Charles Srstka <<a href="mailto:cocoadev@charlessoft.com" class="">cocoadev@charlessoft.com</a>> のメッセージ:<br class=""><br class=""></div><blockquote type="cite" class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div class=""><blockquote type="cite" class="">On Aug 23, 2016, at 2:33 PM, Robert Widmann via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""></blockquote><div class=""><blockquote type="cite" class=""><br class="Apple-interchange-newline"><div class=""><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">2016/08/22 14:30、David Cordero via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> のメッセージ:<br class=""><br class=""></div><blockquote type="cite" class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div class=""><div dir="ltr" class=""><br class=""><div class=""><b class="">The problem:</b></div><div class="">At the moment, looking at the code of a class or a struct implementing a protocol, it is hard to know what methods are actually implementing the protocol and what other methods are just part of the code of the class or struct.<br class=""></div><div class=""><br class=""></div></div></div></blockquote><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br class=""></div><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">That seems like a feature, not a bug. Why should I as an author care whether a method contributes to a protocol conformance or not if the compiler can tell me that kind of information itself?</div></div></blockquote><div class=""><br class=""></div><div class="">Being able to reason about your code, what it does, and what it’s for is undesirable?</div></div></div></blockquote><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br class=""></div><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">That's not an answer to the question I asked. Why is this significant enough to warrant an entire keyword? The clutter of a whole keyword that does nothing but wait for a developer to make a source-compatible binary-breaking change to an interface does not seem worth it. Maybe you can convince me otherwise. </div></div></blockquote><div class=""><br class=""></div><div class="">Same reason overriding a class method warrants a keyword. It expresses the purpose more clearly, and allows the compiler to catch mistakes for us.</div><br class=""></div></div></blockquote><div class=""><br class=""></div><div class="">That's just it: The class of mistakes one can make by not being explicit about overrides is significantly more dangerous than the class of mistakes caused by dead code leftover from trimming protocols.</div></div></div></div></div></div></blockquote><div class=""><br class=""></div><div class="">I am in the middle of a large refactor of code that was originally Objective-C and then Swift written like Objective-C, to more idiomatic protocol-oriented Swift. I am finding that in Swift’s POP idiom, protocols with overrides are serving very nearly the same purpose that overrides were serving in the old design; hence, I don’t really think either is more or less dangerous than the other.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div class=""><div class=""><div class=""><blockquote type="cite" class=""><div class=""><div class=""><blockquote type="cite" class=""><div class=""><blockquote type="cite" class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div class=""><div class=""><blockquote type="cite" class=""><blockquote type="cite" class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div class=""><div dir="ltr" class=""><div class="">```</div></div></div></blockquote><blockquote type="cite" class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div class=""><div dir="ltr" class=""><div class="">protocol MyProtocol {</div><div class=""> func myMethod() -> String</div><div class="">}</div><div class=""><br class=""></div><div class="">class MyClass: MyProtocol {</div><div class=""><br class=""></div><div class=""> <span class="Apple-converted-space"> </span><b class="">conform</b> func myMethod() -> String {</div><div class=""> return "Yuhuuu,I am conforming<span class="Apple-converted-space"> </span><a href="smb://o//" class="">\\o//</a>"</div><div class=""> }</div><div class=""><br class=""></div><div class=""> func whatever() {</div><div class=""> print("I am a boring method and I don't conform anything")</div><div class=""> }</div><div class="">}</div><div class="">```</div><div class=""><br class=""></div><div class="">It would be something similar to the current keyword `override` but for protocols. </div><div class=""><br class=""></div><div class="">Apart from improving code readability, It would allow the detection, in compilation time, of errors due to code evolution. For example redundant methods that no longer conform anything once the requirement is removed from the protocol for whatever reason.</div></div></div></blockquote><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br class=""></div><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">If you make a breaking change to a protocol like this, you should have gone through a deprecation cycle to indicate to your clients the appropriate changes you're going to make to the protocol. This aspect of the change seems to if not encourage, highlight, bad behavior.</div></blockquote></div><br class=""><div class="">What if it’s your own code and all the callers are internal? What if you’re still developing the protocol and haven’t released the API interface yet?</div></div></blockquote><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br class=""></div><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">Then your concerns are local enough that you know where<span class="Apple-converted-space"> </span><i class="">all</i> implementations of the protocol lie and whether they require deletion or not. The point about deprecation cycles still stands in all the cases you mention. Just because the interface is private doesn't mean you can't take responsibility for keeping it as clean as you can.</div><br class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><blockquote type="cite" class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div class=""><div class=""><br class=""></div><div class="">Charles</div><div class=""><br class=""></div></div></blockquote><br class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">tl;dr It seems like all of this can be subsumed by us warning about dead code.</div></div></blockquote></div><br class=""><div class="">Did you look at my examples earlier in the thread? Neither of those would be caught by warning about dead code.</div></div></blockquote><div class=""><br class=""></div><div class="">The example involving the default implementation is most compelling, but it indicates that your proposed solution should focus on the protocol extension and not the implementing declaration. Perhaps reusing one of our existing keywords can help here</div><div class=""><br class=""></div><div class=""><div class=""><span style="background-color: rgba(255, 255, 255, 0);" class="">protocol P {</span></div><div class=""><span style="background-color: rgba(255, 255, 255, 0);" class=""> func foo() {}</span></div><div class=""><span style="background-color: rgba(255, 255, 255, 0);" class="">}</span></div><div class=""><span style="background-color: rgba(255, 255, 255, 0);" class=""><br class=""></span></div><div class=""><span style="background-color: rgba(255, 255, 255, 0);" class="">extension P {</span></div><div class=""><span style="background-color: rgba(255, 255, 255, 0);" class=""> default func foo() {}</span></div><div class=""><span style="background-color: rgba(255, 255, 255, 0);" class="">}</span></div><div class=""><br class=""></div><div class=""><span style="background-color: rgba(255, 255, 255, 0);" class="">struct S: P {}</span></div></div><div class=""><br class=""></div><div class="">Of course, this change would be potentially source-breaking either way - I don't like the sound of an "optional keyword”. </div></div></div></div></div></div></blockquote><div class=""><br class=""></div><div class="">I can come up with a similar example without the mistake being in the extension, though:</div><div class=""><br class=""></div><div class="">protocol P {</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>func foo() {}</div><div class="">}</div><div class=""><br class=""></div><div class="">extension P {</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>func foo() { print(“Default Behavior”) }</div><div class="">}</div><div class=""><br class=""></div><div class="">struct S: P {</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>func foo() { print(“Specific Behavior”) }</div><div class="">}</div><div class=""><br class=""></div><div class="">So far, so good. But now I realize that the original protocol needs an argument:</div><div class=""><br class=""></div><div class=""><div class="">protocol P {</div><div class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>func foo(bar: String) {}</div><div class="">}</div><div class=""><br class=""></div><div class="">extension P {</div><div class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>func foo(bar: String) { print(“Default Behavior; bar is \(bar)”) }</div><div class="">}</div><div class=""><br class=""></div><div class="">struct S: P {</div><div class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>func foo() { print(“Specific Behavior”) } // Whoops, forgot to update this method, and now it won’t get called<span style="font-size: 11px;" class="">—</span>and we of course won’t see the carnage until runtime.</div><div class="">}</div></div><br class=""><blockquote type="cite" class=""><div class=""><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div class=""><div class=""><div class=""><div class="">Either way, we can all agree we need better diagnostics around these cases.</div></div></div></div></div></div></blockquote><br class=""></div><div class="">No doubt.</div><div class=""><br class=""></div>Charles<div class=""><br class=""></div></div></blockquote><blockquote type="cite" class=""><div class=""><span class="">_______________________________________________</span><br class=""><span class="">swift-evolution mailing list</span><br class=""><span class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a></span><br class=""><span class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br class=""></div></blockquote></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></div></body></html>