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

[Ross O'Brien]

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 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/20160319/42686db7/attachment.html>