<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 feel like this should be added to the "common proposal caveats", but please include a discussion of how this affects retroactive modeling (adding a protocol to a type you don't own that already has the appropriate members). Previous discussions about "implement" (usually "implements") usually fizzle out at this point.</div><div class=""><br class=""></div><div class="">(IIRC last time we got to "it's required if the member is in the same module, but allowed to be absent otherwise", which is fairly reasonable but probably still needs to be thought through.)</div><div class=""><br class=""></div><div class="">Jordan</div><div class=""><br class=""></div><br class=""><div><blockquote type="cite" class=""><div class="">On Mar 18, 2016, at 16:58 , Victor Gao via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><font face="HelveticaNeue" style="font-size: 14px;" class="">Hello everybody. Please excuse this proposal’s poor formatting. I am very new to swift-evolution and don’t yet know how to do a formatted proposal. :)</font></div><div class=""><font face="HelveticaNeue" style="font-size: 14px;" class=""><br class=""></font></div><div class=""><br class=""></div><div class=""><font size="5" face="HelveticaNeue" class=""><b class="">Proposal</b></font></div><div class=""><font face="HelveticaNeue" style="font-size: 14px;" class=""><br class=""></font></div><div class=""><font face="HelveticaNeue" style="font-size: 14px;" class="">I am proposing to add an </font><font style="font-size: 14px;" face="Courier" class="">implement</font><font face="HelveticaNeue" style="font-size: 14px;" class="">&nbsp;keyword to go with protocol method implementations like the </font><font style="font-size: 14px;" face="Courier" class="">override</font><font face="HelveticaNeue" style="font-size: 14px;" class="">&nbsp;keyword.</font></div><div class=""><font face="HelveticaNeue" style="font-size: 14px;" class=""><br class=""></font></div><div class=""><br class=""></div><div class=""><font size="5" face="HelveticaNeue" class=""><b class="">Motivation</b></font></div><div class=""><span style="font-size: 14px;" class=""><font face="HelveticaNeue" class=""><br class=""></font></span></div><div class=""><span style="font-size: 14px;" class=""><font face="HelveticaNeue" class="">When writing an implementation for a protocol method, there is no indication that the method is an implementation of a protocol method. Unless it is a well-known protocol like </font><font face="Courier" class="">UITableViewDataSource</font><font face="HelveticaNeue" class="">, there is simply no way to know if the method is provided by a protocol or the enclosing class. Right now, the only way to guess if a method is protocol-provided is if it follows the pattern of </font><font face="Courier" class="">someObjectOrView(_: requestSomething:) </font><font face="HelveticaNeue" class="">or </font><font face="Courier" class="">someObjectOrView(_: somethingDidHappen:)</font><font face="HelveticaNeue" class="">. But since non-Cocoa protocol methods may not follow that pattern, they will not be so easy to guess. </font><span style="font-family: HelveticaNeue;" class="">Here’s an example illustrating the problem:</span></span></div><div class=""><font face="HelveticaNeue" style="font-size: 14px;" class=""><br class=""></font></div><div class=""><font style="font-size: 14px;" face="Courier" class=""><font color="#b92d5d" class="">func</font> recordInDatabase(database: <font color="#008cb4" class="">TJDatabase</font>, atIndexPath indexPath: <font color="#7b219f" class="">NSIndexPath</font>) -&gt; <font color="#008cb4" class="">TJRecord</font> {</font></div><div class=""><font style="font-size: 14px;" face="Courier" class="">&nbsp; &nbsp; <font color="#669c35" class="">//…</font></font></div><div class=""><font style="font-size: 14px;" face="Courier" class="">}</font></div><div class=""><font style="font-size: 14px;" face="Courier" class=""><br class=""></font></div><div class=""><font face="HelveticaNeue" class=""><span style="font-size: 14px;" class="">Is this a protocol method implementation, or simply a method declaration? Well, it <i class="">looks</i>&nbsp;like a protocol method implementation, but how can one be sure? There is no way to definitely know unless you are familiar with it or you found its declaration after searching in the whole project, worse in huge projects. The method above just seems too&nbsp;“ordinary” to be a protocol method implementation. Even worse, some developer might come around and even rename that method, and there would be an error, then he has to fish around for the protocol method he’s missing. Assuming that he finally found it (if the protocol is small enough), he might even implement it <i class="">again</i>&nbsp;with the <i class="">same</i> code as the renamed method. We can see the problem here.</span></font></div><div class=""><font face="HelveticaNeue" class=""><span style="font-size: 14px;" class=""><br class=""></span></font></div><div class=""><font face="HelveticaNeue" class=""><span style="font-size: 14px;" class="">Or, let’s think about this: how would it feel if there is no </span></font><font face="Courier" style="font-size: 14px;" class="">override</font><font face="HelveticaNeue" class=""><span style="font-size: 14px;" class=""> &nbsp;keyword? How would one know if a method is an override or not? We can see how this relates to the confusion with protocol method implementations.</span></font></div><div class=""><font face="HelveticaNeue" class=""><span style="font-size: 14px;" class=""><br class=""></span></font></div><div class=""><br class=""></div><div class=""><font face="HelveticaNeue" size="5" class=""><b class="">Proposed solution</b></font></div><div class=""><span style="font-size: 14px;" class=""><font face="HelveticaNeue" class=""><br class=""></font></span></div><div class=""><span style="font-size: 14px;" class=""><font face="HelveticaNeue" class="">The proposed solution is to add an </font><font face="Courier" class="">implement</font><font face="HelveticaNeue" class=""> keyword, which improves the code above to this:</font></span></div><div class=""><span style="font-size: 14px;" class=""><font face="HelveticaNeue" class=""><br class=""></font></span></div><div class=""><span style="font-size: 14px;" class=""><font face="Courier" class=""><font color="#b92d5d" class="">implement func</font> recordInDatabase(database: <font color="#008cb4" class="">TJDatabase</font>, atIndexPath indexPath: <font color="#7b219f" class="">NSIndexPath</font>) -&gt;&nbsp;</font><span style="font-family: Courier;" class=""><font color="#008cb4" class="">TJRecord</font> {</span></span></div><div class=""><font face="Courier" style="font-size: 14px;" class="">&nbsp; &nbsp; <font color="#669c35" class="">//…</font></font></div><div class=""><font face="Courier" style="font-size: 14px;" class="">}</font></div><div class=""><font face="Courier" style="font-size: 14px;" class=""><br class=""></font></div><div class=""><font face="HelveticaNeue" class=""><span style="font-size: 14px;" class="">Now it is very clear that we are implementing a protocol method rather than declaring a method. The code is much clearer, and it doesn’t hurt the readability either.</span></font></div><div class=""><font face="HelveticaNeue" class=""><span style="font-size: 14px;" class=""><br class=""></span></font></div><div class=""><br class=""></div><div class=""><b style="font-family: HelveticaNeue;" class=""><font size="5" class="">Detailed design</font></b></div><div class=""><br class=""></div><div class=""><span style="font-size: 14px;" class=""><font face="HelveticaNeue" class="">When overriding implemented protocol methods from a superclass, the </font><font face="Courier" class="">override</font><font face="HelveticaNeue" class=""> keyword is still used:</font></span></div><div class=""><span style="font-size: 14px;" class=""><font face="HelveticaNeue" class=""><br class=""></font></span></div><div class=""><div class=""><span style="font-size: 14px;" class=""><font face="Courier" class=""><font color="#b92d5d" class="">override func</font>&nbsp;recordInDatabase(database:&nbsp;<font color="#008cb4" class="">TJDatabase</font>, atIndexPath indexPath:&nbsp;<font color="#7b219f" class="">NSIndexPath</font>) -&gt;&nbsp;</font><span style="font-family: Courier;" class=""><font color="#008cb4" class="">TJRecord</font>&nbsp;{</span></span></div><div class=""><font face="Courier" style="font-size: 14px;" class="">&nbsp; &nbsp;&nbsp;<font color="#b92d5d" class="">return</font> <font color="#b92d5d" class="">super</font>.<font color="#00a3d7" class="">recordInDatabase</font>(database, atIndexPath: indexPath)</font></div><div class=""><font face="Courier" style="font-size: 14px;" class="">}</font></div></div><div class=""><font face="HelveticaNeue" class=""><span style="font-size: 14px;" class=""><br class=""></span></font></div><div class=""><font face="HelveticaNeue" size="5" class=""><b class="">Impact on existing code</b></font></div><div class=""><br class=""></div><div class=""><span style="font-size: 14px;" class="">Existing code would be changed to include the <font face="Courier" class="">implement</font> keyword in appropriate places. This could be handled via the Swift latest syntax converter in Xcode.&nbsp;</span></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div></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>