[swift-evolution] [swift evolution] [proposal] Proposal to add "implement" keyword to denote protocol method implementation

[Jordan Rose]

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.

(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.)

Jordan


> On Mar 18, 2016, at 16:58 , Victor Gao via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 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. :)
> 
> 
> Proposal
> 
> I am proposing to add an implement keyword to go with protocol method implementations like the override keyword.
> 
> 
> Motivation
> 
> 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 UITableViewDataSource, 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 someObjectOrView(_: requestSomething:) or someObjectOrView(_: somethingDidHappen:). But since non-Cocoa protocol methods may not follow that pattern, they will not be so easy to guess. Here’s an example illustrating the problem:
> 
> func recordInDatabase(database: TJDatabase, atIndexPath indexPath: NSIndexPath) -> TJRecord {
>     //…
> }
> 
> Is this a protocol method implementation, or simply a method declaration? Well, it looks 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 “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 again with the same code as the renamed method. We can see the problem here.
> 
> Or, let’s think about this: how would it feel if there is no override  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.
> 
> 
> Proposed solution
> 
> The proposed solution is to add an implement keyword, which improves the code above to this:
> 
> implement func recordInDatabase(database: TJDatabase, atIndexPath indexPath: NSIndexPath) -> TJRecord {
>     //…
> }
> 
> 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.
> 
> 
> Detailed design
> 
> When overriding implemented protocol methods from a superclass, the override keyword is still used:
> 
> override func recordInDatabase(database: TJDatabase, atIndexPath indexPath: NSIndexPath) -> TJRecord {
>     return super.recordInDatabase(database, atIndexPath: indexPath)
> }
> 
> Impact on existing code
> 
> Existing code would be changed to include the implement keyword in appropriate places. This could be handled via the Swift latest syntax converter in Xcode. 
> 
> 
> 
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160318/488fbe36/attachment.html>