<div dir="ltr">On Tue, Aug 23, 2016 at 12:11 AM, Charlie Monroe <span dir="ltr"><<a href="mailto:charlie@charliemonroe.net" target="_blank">charlie@charliemonroe.net</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style: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></blockquote><div><br></div><div>I think we're having a language barrier here :) Sub-par means inadequate, and I think we're all in agreement that this behavior is inadequate.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><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.</div></div></blockquote><div><br></div><div>I think we should separate out the discussion about library evolution and versioning. There's a huge amount of proposed and (I think) planned work about that. Maybe the core team could chime in on how up-to-date this document is:</div><div><br></div><div><a href="https://github.com/apple/swift/blob/master/docs/LibraryEvolution.rst">https://github.com/apple/swift/blob/master/docs/LibraryEvolution.rst</a><br></div><div><br></div><div>If the true motivating problem here has to do with library evolution, then we should probably study that document and wait to see how that planned work turns out.</div><div><br></div><div>But if I understand it correctly, the true motivating problem here is the poor experience of conforming to a protocol, the errors caused by typos that effectively make protocol requirements stringily typed, and the resultant unanticipated behaviors that arise, then we can have a useful discussion about these issues without also trying to solve library evolution with a single keyword.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div>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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style: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></blockquote></div><br></div></div>