> On May 18, 2016, at 12:28 AM, Vladimir.S via swift-evolution
> <[email protected]> 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
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
