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

[Vladimir.S]

 > I (personally) still don’t feel like the cases handled by “reimplement” 
are important to distinguish from “implement”.

The main idea was to decorate *type method* that is same as *method in 
protocol extension* if that method was *not declared in protocol* itself.

So, with very high _possibility_ developer *forgot* (or don't know yet) the 
rule of static dispatch for such method and *thinks* right now that type's 
method will be called if type of reference is protocol.

In contrast: implemented methods *declared* in protocol definition, will 
be(in most cases, yes) dispatched dynamically and so type's methods will be 
called if reference is a protocol.

Probably 'reimpements' not the best name here, probably 'overload' can be 
used here.. Or some other to show "Yes, I know this is not the protocol 
requirement method, I'm aware of its behavior and know that the same method 
exists in protocol extension only(no in protocol itself)"


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

The idea of proposal is that Swift should help us in situation of protocol 
conformance:
1. To self-document the code : clearly see which method was implemented 
specially to fulfill the protocol requirements
2. Raise error/warning if conformed protocol did change: let's consider 
removed requirement in protocol - with my proposal Swift will flag out that 
some method decorated with 'implements' didn't declared in protocol. Even 
important if protocol requirement changed and such requirement has *defailt 
implmementation* - i.e. without 'implements' keyword, our type, previously 
implemented all needed methods, will still have them, assuming all is ok, 
no errors, but protocol's requirement will call the default implementation 
and 'old' implemented methods will never be called.

But I also support your suggestion regarding public methods of type 
extension that conforms to protocol.
This way or another IMO we need a way to show(for reader *and* for 
compiler) that some methods were implemented just to satisfy the protocol.


On 23.05.2016 7:53, Douglas Gregor 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.
>
> 	- Doug
>
>