[swift-evolution] [Pitch] Requiring special keyword to mark protocol implementation methods

[L. Mihalkovic]

> On May 23, 2016, at 6:53 AM, Douglas Gregor via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
>> On May 18, 2016, at 12:28 AM, Vladimir.S via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> I'd like to discuss declaration of protocol implementation in types.
>> 
>> Ideas of this pitch is partially based on Erica Sadun's thread:
>> [Pitch] Requiring proactive overrides for default protocol implementations.
>> http://thread.gmane.org/gmane.comp.lang.swift.evolution/15496
>> And on this draft of proposal:
>> https://gist.github.com/erica/fc66e6f6335750d737e5512797e8284a
>> 
>> I had read "Winding down the Swift 3 release" message, but feel like this proposal makes "improvements to the consistency and feel of the language"
>> and supports the "goal of making Swift 4 as source compatible with Swift 3 as we can reasonably accomplish". Or this can be discussed as 'after Swift 3.0' feature.
>> 
>> 
>> The main idea of my proposal
>> 
>> Swift should help us to be explicit about what methods were defined in type specifically to fulfill a protocol requirements. And so we will have more understandable and self-documented code that is explicit regarding the fact of protocol implementation(for reader of our code and for compiler).
>> 
>> Additionally this can help to reduce potential problems/error/misunderstanding in case some protocol requirement(method) were *removed* - in this case (currently) our type will still have a method as implementation but no such requirement in conformed protocol yet.
>> 
>> 
>> Details
>> 
>> I propose to introduce *implement* keyword to 'mark' the methods(in type) that were defined in order to conform to protocol.
> 
> I like this better than using the “override” or “required” keywprds.
> 
>> Also, *reimplement* keyword is proposed to reflect the fact that method is declared in *both* : in the type and in protocol extension (only in extension, no definition of the method in protocol itself)
> 
> I (personally) still don’t feel like the cases handled by “reimplement” are important to distinguish from “implement”.
> 
> Without digging deeply into your rules, I’d like to reiterate my own (personal!) perspective on why I don’t think we need a keyword here. With a few exceptions, one can freely break up a type’s definition into a number of different extensions. A fairly common style I’ve seen it to use a unique extension for each protocol conformance, because it’s great for readability: this is the functionality that is associated with a particular protocol conformance. This style conveys essentially what the “implements” keyword conveys: that the programmer intends to implement the protocol, but it does so without any extra syntax. Moreover, if we assume that this is good style and widely practiced, the compiler can use it as a cue: non-private declarations that are within an extension that states conformance to P, that are similar to some requirement in P but aren’t used to satisfy any require, are suspicious and should produce a warning.
> 

Warning on non-private non-conformance yielding methods (helpers) is likely a good thing that would cleanly address some of the issues listed here:

https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160516/018560.html

Depending on where things go with protocols, you might still end-up having override creeping its nose, but it could simply be the result of applying current swift rules.


>    - Doug
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution