I recently had the misfortune of deleting what turned out to be a necessary function, because it was an optional requirement of a protocol and wasn't being called by any code in the project, so I would sympathise with this.
On the other hand I've also written protocols composed entirely of functions that an established type already has, so I can retroactively have the type conform. (For example, there's no 'ArithmeticOperation' protocol which Int and Double both conform to, even though they both have a `+ (lhs:Self, rhs:Self) -> Self` operator, so you have to roll your own... unless that should be a proposal itself.) It would be impossible to require a function to use your 'implements' keyword to conform to a protocol in an importing module. On Fri, Mar 18, 2016 at 11:58 PM, Victor Gao via swift-evolution < swift-evolution@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@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution > >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution