<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=""><div class="">I don't see it as sub-par in this example (this actually happened to me):</div><div class=""><br class=""></div><div class="">@objc protocol Foo {</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>optional func bar()</div><div class="">}</div><div class=""><br class=""></div><div class="">class FooImpl: Foo {</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>func bar() { ... }</div><div class="">}</div><div class=""><br class=""></div><div class="">Now imagine that bar() gets renamed in the protocol to baz(). You get no warnings, nothing - since the bar() was optional (or can have default implementation as Chalers mentioned). FooImpl still conforms to Foo and bar() can live on there happily.</div><div class=""><br class=""></div><div class="">Yes, this could be solved by Xcode having a refactoring feature that works for Swift, or that you search & replace when renaming, but still doesn't solve when a 3rd party library does this and suddenly the behavior of your app changes completely. This goes against the compile-time safety Swift is about.</div><div class=""><br class=""></div><div class="">Currently, when you mark a method on a protocol as</div><div class=""><br class=""></div><div class=""><div style="margin: 0px; font-size: 9px; line-height: normal; font-family: Menlo;" class=""><span style="font-variant-ligatures: no-common-ligatures; color: #bb2ca2" class="">@available</span><span style="font-variant-ligatures: no-common-ligatures" class="">(*, unavailable, renamed=</span><span style="font-variant-ligatures: no-common-ligatures; color: #d12f1b" class="">"baz"</span><span style="font-variant-ligatures: no-common-ligatures" class="">)</span></div></div><div class=""><br class=""></div><div class="">you do not get any warnings either - perhaps that's the issue here. On the other hand, the naming may be completely coincidental and you can already have a method called bar() and it would then be impossible to conform to Foo unless you rename bar().</div><div class=""><br class=""></div><div class="">What I'd propose is not to make keyword optional. In case you implement the members declared by the protocol, mark it as @conforming (or conforming keyword?).</div><div class=""><br class=""></div><div class="">If it's retroactive modeling, redeclare the members. E.g.:</div><div class=""><br class=""></div><div class="">extension Bar: Foo {</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>// The implementation will be taken from Bar's main implementation</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>@conforming func bar()</div><div class="">}</div><div class=""><br class=""></div><div class="">But yeah, it's a bit of boilerplate...</div><br class=""><div><blockquote type="cite" class=""><div class="">On Aug 23, 2016, at 12:41 AM, Xiaodi Wu 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="">There's been agreement even from the core team that the quality of diagnostics when conforming to a protocol is sub-par.<br class=""><br class="">The modified rule you propose has also been suggested before. The reason it doesn't help is that (1) if a method signature is mismatched accidentally due to a typo, you get a compilation error already because your type doesn't conform to the protocol (it's the quality of the error message that needs improvement); (2) otherwise, if your type fulfills all protocol requirements but also implements an additional method unnecessary for conformance, what is the harm that is being prevented by a compiler error?<br class=""><br class=""><div class="gmail_quote"><div dir="ltr" class="">On Mon, Aug 22, 2016 at 17:30 Charles Srstka <<a href="mailto:cocoadev@charlessoft.com" class="">cocoadev@charlessoft.com</a>> wrote:<br class=""></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" class=""><blockquote type="cite" class="">On Aug 22, 2016, at 5:19 PM, Xiaodi Wu via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:<br class=""></blockquote><div class=""><blockquote type="cite" class=""><br class=""><div class=""><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important" class="">This has been proposed before in the past by several others (myself being one of them).</span><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important" class="">The key problem is that it cannot accommodate retroactive modeling. That is, you would not be able to conform existing types, the code for which you do not control, to a protocol of your own design. Retroactive modeling is an essential feature of Swift protocol-oriented programming.</span></div></blockquote></div><br class=""></div><div style="word-wrap:break-word" class=""><div class="">Then how about making the keyword optional? A method or property with the keyword before it would throw an error if it didn’t exist in one of the protocols your type implements. This way, if you intended a method to satisfy a protocol but left a typo in it, or you changed the protocol’s signature in a refactoring or something, you’d get notified instead of not finding out about it until runtime.</div></div><div style="word-wrap:break-word" class=""><div class=""><br class=""></div><div class="">Charles</div><div class=""><br class=""></div></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=""></body></html>