On 20.09.2016 3:03, Xiaodi Wu via swift-evolution wrote:
I definitely think Vladimir's suggestion is a great starting point, IMO.

However, I think it could be improved in one key respect where previous
proposals using `override` are superior. Namely, the proposed `implement`
keyword adds no additional safety when a type implements a protocol
requirement that doesn't have a default implementation. This is because, if

Yes, *at the moment of writing* the type's code there could be no default implementation for protocol requirement. But, *at the moment of compilation* such default implementation could appear.

Let's discuss such scenario in case we'll take your suggestion:

You got SomeClass.swift file, 3rd party file you don't want to change or changes are not allowed. Content:

public protocol SomeProtocol {
        func foo()

public class SomeClass : SomeProtocol {
func foo() {...} // no default implementation *at the moment of writing*, no need in `overload`

Now, you adds SomeClass.swift file to your project and in some *other* file you write:

extension SomeProtocol {
        func foo() {...}

As you see, you don't control the SomeClass.swift but you suggest in this case should be defined with `override`.

With 'implement' will be marked initially and will save us if protocol's requirement PLUS default implementation changed.

there's a "near-miss" typo in the function signature, an error is already
generated at compile time because the type doesn't conform to the stated
protocol. Currently, the error is very unhelpful, but IMO that's a

Even, if `implement` will not add safety in case there is no default implementation of protocol's requirement *now*, it will add safety if you decide to add such default implementation at some point of time or in some other point of your project. And this `implement` will save us in this case, as you expresses your intention explicitly and compiler will check this.

straight-up bug; improving the diagnostics for that error can be done
without evolution.

On the other hand, if we require `implement`, the simplest use case of
conforming a type to a protocol with no default implementations would take
more effort but provide no benefit to justify that additional effort.

I don't believe the requirement to add just one word `implement` on the same line with method/prop declaration would take more effort to conform to protocol. I don't see see real big difference in these lines:

class Foo : Bar {
        func foo() {...}

class Foo : Bar {
        implement func foo() {...}

But I see that foo is a protocol requirement and compiler will help me with this. Also this add clarity when you read some one's code.

Moreover (I think a core team member has expressed this more elegantly in
the past), there's the philosophical point that POP represents the
theoretical process by which we discover and express our discovery that
certain types happen to share common semantic characteristics. In that
conception of POP, it would be backwards to declare a certain member as
fulfilling certain protocol requirements.

Well.. I do believe we need some golden middle between "theoretical process" and C++ ;-) I.e. we are discussing a real-word programming language, which we use to build low-level utils, web backend applications, macOS apps, iOS apps etc. IMO we need a balance between a shiny theory and ugly bugs we *will* have because this theory don't allow our compiler to help us.

Probably there is another perfect way to solve the initial problem, probably core team already invented something cool and we just don't know about this yet. But for now I think its worth to add the `implement` keyword to Swift.

So, if such a source breaking change were to be in scope for Swift, I would
suggest modifying Vladimir's proposal to use `override` instead and

If the community and core team will accept the idea to mark method defined in type as protocol's requirement (without any relation to existence of default implementation) only with `override` - I think this also will be a good solution. I.e. when we see `override` in type definition, we understand that this type implements something that exists in its "super" type in wide sense i.e. in its super class or in one of its protocols.

So, personally I don't insist on `implement` word, but propose some 'marker' to mark methods in type implemented exactly as implementation for some requirement.

Probably this really could be `override` - as Swift propose itself as POP language, there should be no big difference if we override a method of super class or 'override' a method of one of protocols. Just like `override` for super class method, `override` for protocol implementation method is here just because this method *depend* on what is defined in conformed protocol.

But again, `override` IMO should not depend on if there is a default implementation in protocol.

requiring the keyword only when a default implementation is being
overridden. To accommodate retroactive conformance, we could either propose
that `extension Foo : Bar` is automatically understood to contain members
that override default implementations (as Vladimir has essentially
suggested), or stipulate that we must write `extension Foo : override Bar`.
This has the advantage of not introducing an additional keyword and avoids
the seemingly reduplicative spelling `extension Foo : implement Bar` (for
what else would an `extension Foo : Bar` reasonably do but implement the
requirements of Bar?).

On Mon, Sep 19, 2016 at 3:10 PM, Goffredo Marocchi via swift-evolution
< <>> wrote:

    If Swift 4 will make it impossible to tackle this again, I do not think
    discussing this can be avoided for Swift 3.1... I am afraid we are
    rushing into Swift 4 a bit too quickly, but perhaps it is just silly
    old me :).

    Sent from my iPhone

    On 19 Sep 2016, at 19:18, Charles Srstka via swift-evolution
    < <>> wrote:

    On Sep 19, 2016, at 12:10 PM, Vladimir.S via swift-evolution
    < <>> wrote:

    On 17.09.2016 6:32, Xiaodi Wu via swift-evolution wrote:

    Let me give a concrete example of how retroactively modeling is used.

    Karl is suggesting interesting but complex and IMO too much
    code-breaking idea that I don't believe can be implemented at all in
    a reasonable amount of time to be a part of Swift as soon as
    possible, to address the discussed issue with protocols.

    I wonder what objections could be made on the solution proposed
    below, which should solve a major(IMO) number of issues with
    protocol conformance and introduce only 1 keyword. Such solution
    will make Swift better as Protocol-Oriented language and later we
    can even improve it, but it can already solve a big number of issues:

    1. As soon as possible we add 'implement' keyword which is required
    to mark method/property that was defined in type or extension
    exactly to conform to some protocol.

    2. The 'implement' required only at a moment of 'direct'
    conformance, i.e. when you declare methods/props of the
    type/extension that explicitly conformed to protocol.

    3. Retrospective conformance will not require this keyword and will
    work for now just like it is working today.

    4. Later, if this will be possible at all, we can extend this model
    to support separate implementation of protocols with same
    requirements in the same type, explicit protocol name in implemented
    methods/props and improvements for retrospective conformance. For
    example some variants for *future* improvements:

    4.1 Different implementation for different protocols
    class Foo : ProtocolA, ProtocolB {
     implement(ProtocolA) func foo() {...}
     implement(ProtocolB) func foo() {...}
    class Foo : ProtocolA, ProtocolB {
     implement ProtocolA {
    func foo() {...}
     implement ProtocolB {
    func foo() {...}

    4.2 Retrospective conformance: What is the main problem with
    retrospective conformance? As I see it now(correct me, if I missing
    something), the problem arises in such situation:
    * we *expect* that some method(s) in type will play the role of
    implementation of protocol's requirements, so we retrospectively
    conform that type to the protocol.
    * but protocol has default implementation for its requirements
    * and type's methods, that we *expect* to play roles for protocol
    implementation, has different parameters or slightly different
    method name at all.

    I.e. when we have this set of code logic:

    type T {
     func foo()

    protocol P {
     func foo(x: Int)

    extension P {
     func foo(x: Int) {...}

    extension T : P { // expect foo in T will play role of

    I support the opinion that it is not an option to require to
    explicitly list conformed methods/props in type extension for
    retrospective conformance.
    But I do believe we need a way to *express our intention* regarding
    the retrospective conformance: do we expect that type already
    contains implementation for some protocol's requirements OR we are
    aware that protocol can have defaults for some methods and our type
    does not contains some implementations.

    So, the solution here IMO is some syntax to express that intention.
    Right now I think that we can use current syntax "extension T : P"
    to keep it working as it now works: "I'm aware of all the names,
    defaults etc. Treat this as usually you did". But for example
    something like "extension T: implement P {..}" or "extension T:
    P(implement *) {..}" will say that we *expect* that all requirements
    of P protocol should be implemented inside T type. Or some syntax
    inside extension to specify the list of methods/props we expect to
    be implemented in T. Or "extension T : P(implement foo, bar(x:y:))
    {..}".. Should be discussed.

    But again, IMO this could be discussed later, after we'll have
    'implement' for most important place - in type definition for
    method/prop that we created exactly for the conformed protocol.

    I would be completely +1 on this.


    swift-evolution mailing list <>

    swift-evolution mailing list <>

swift-evolution mailing list

swift-evolution mailing list

Reply via email to