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


_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to