Pre-Pitch: Explicit protocol fulfilment with the 'conformance' keyword

[tera]

@gwendal.roue

Anyway, the pitch does not require all witnesses to be explicitly marked with a keyword. Sometimes those witnesses are defined in source code you can't even access (there is an example right above)!

I believe we are talking about the same thing then, just don't see this mentioned in the alternatives considered section (see below).

• There are valid programs where the fulfillment has to be added at locations where the target protocol is not statically known.

which we could be resolved via a kind of marker:

extension Foo: HasFooAndBar {
    some-marker conformance func foo() // to denote it is defined elsewhere
    conformance func bar() { ... }
}

(intriguely "some-marker" can literally be empty - i.e. no body would be a marker in itself.)

@gwendal.roue

Then the rules of the Detailed Design section of the pitch tell that it is possible to use the conformance keyword on both methods (if you can and want):

struct S {}
extension S {
    // OK: matches HasFooAndBar.foo()
    conformance func foo() { ... }
}

I have in mind more intriguing cases when it is not possible adding that conformance upfront. Examples:

protocol Foo1 { func foo() }
protocol Foo2 { func foo() }

class Base {
    func foo() {...} // not necessarily Foo1's or Foo2's
}

class Derived: Base, Foo1 {
    // We won't add "foo()" here as it is already provided by Base.
    // Although we haven't stated that "foo()" is "Foo1 conformance".
    // which makes it "duck typing" conformance.
    // I believe this conformance needs to be explicit, like this:

    conformance func foo()

    // to state conformance explicitly.
    // note: no body was provided here
}

• This would break backward compatibility.

Indeed.
Not the end of the world but definitely increases the stakes.

• Compiler performance: the conformance check has a cost.

I believe these checks (have to) happen anyway.

• This would force programmers to use it on fortuitous fulfillments, ruining the very goal of the keyword which is to declare an intent.
• Adding a requirement to a protocol would create an opportunity for fortuitous fulfillment, and become a breaking change.

I'm afraid I didn't get these two.

This idea creates a problem, because such an extension would only accept declarations that fulfill requirements. This would be an annoyance for programmers who group inside a single extension methods that are related to a conformance.

// Just annoying
conformance extension SortedArray: Collection {
    var first: ...  // OK
    var last: ...   // OK
    var median: ... // error: property 'median' does not fulfill any requirement of the protocol 'Collection'.
}```

I'd say "a minor inconvenience in some cases, totally fine in others". Note that we have a precedent already: you are adding an extension with a block of related methods to add a feature but you have to add that feature variables into the main type body as you can't add those to an extension.

That said I'm +1 for the pitch even in the current form as I believe it makes swift better than it is now.

Edit: edited the code sample above.