<div dir="ltr">I agree with Charlie Monroe. I think it would improve the compile time safety of Swift, making the keyword non optional. <div><br></div><div>The main issue with retroactive modelling is that it is applied to code to which we might have no control at all. So this boilerplate definition would allow the detection of changes on method signatures on this non controlled code. </div><div><br></div><div>It might be easier to read having two different keywords for the 2 different cases. Something like the following code using `implement` when implementing the protocol and `conform` when retroactive modeling</div><div><br></div>protocol MyProtocol {<br> func method() -> String<br>}<br><br>class MyClass {<div><br> implement func method() -> String {<br> return "World"<br> }<br>}</div><div><br></div><div>class MyNonControlledClass {<br><br> func method() -> String {<br> return "Hello"<br> }<br>}<br><br><br>extension MyNonControlledClass: MyProtocol {<br> conform method() -> String<br>}</div><div><br></div><div><br></div><div>Or even with a general way to declare a full conformance of a protocol:</div><div><br></div><div>extension MyNonControlledClass: conform(MyProtocol) {<br>}<br><div><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 23 August 2016 at 07:11, Charlie Monroe via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><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 don't see it as sub-par in this example (this actually happened to me):</div><div><br></div><div>@objc protocol Foo {</div><div><span style="white-space:pre-wrap"> </span>optional func bar()</div><div>}</div><div><br></div><div>class FooImpl: Foo {</div><div><span style="white-space:pre-wrap"> </span>func bar() { ... }</div><div>}</div><div><br></div><div>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><br></div><div>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><br></div><div>Currently, when you mark a method on a protocol as</div><div><br></div><div><div style="margin:0px;font-size:9px;line-height:normal;font-family:Menlo"><span style="color:#bb2ca2">@available</span><span>(*, unavailable, renamed=</span><span style="color:#d12f1b">"baz"</span><span>)</span></div></div><div><br></div><div>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><br></div><div>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><br></div><div>If it's retroactive modeling, redeclare the members. E.g.:</div><div><br></div><div>extension Bar: Foo {</div><div><span style="white-space:pre-wrap"> </span>// The implementation will be taken from Bar's main implementation</div><div><span style="white-space:pre-wrap"> </span>@conforming func bar()</div><div>}</div><div><br></div><div>But yeah, it's a bit of boilerplate...</div><br><div><blockquote type="cite"><div><div class="h5"><div>On Aug 23, 2016, at 12:41 AM, Xiaodi Wu via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br></div></div><div><div><div class="h5">There's been agreement even from the core team that the quality of diagnostics when conforming to a protocol is sub-par.<br><br>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><br><div class="gmail_quote"><div dir="ltr">On Mon, Aug 22, 2016 at 17:30 Charles Srstka <<a href="mailto:cocoadev@charlessoft.com" target="_blank">cocoadev@charlessoft.com</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"><blockquote type="cite">On Aug 22, 2016, at 5:19 PM, Xiaodi Wu via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br></blockquote><div><blockquote type="cite"><br><div><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">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"><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"><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">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></div><div style="word-wrap:break-word"><div>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"><div><br></div><div>Charles</div><div><br></div></div></blockquote></div></div></div><span class="">
______________________________<wbr>_________________<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/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br></span></div></blockquote></div><br></div><br>______________________________<wbr>_________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br>
<br></blockquote></div><br></div>