> On May 23, 2016, at 6:53 AM, Douglas Gregor via swift-evolution > <swift-evolution@swift.org> 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. >
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@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
