[swift-evolution] Mark protocol methods with their protocol

Rien Rien at Balancingrock.nl
Fri Sep 23 09:22:39 CDT 2016

Hello Martin,

Adding protocol conformance via existing functions can be had in different ways, first it could be done via mapping rules.
I.e. if the API user requests a function A.Foo.foo() and there is only a function A.foo() present, the language rules could allow this to be accepted as the default. This is probably the best option if the impact on existing code should be minimized.

Another way would be to use a little boilerplate and provide a new A.Foo.foo() that calls A.foo(). Not very nice, but it does make the intent very clear.

A third way would be to write something like:

extension A: Foo {
 func foo() use A.foo()

but that is adding an extra keyword, which I think needs to be very carefully considered. I would not suggest it right now.


> On 23 Sep 2016, at 14:58, Martin Waitz <tali at admingilde.org> wrote:
> Hello :)
> Am 2016-09-23 08:50, schrieb Rien:
>> > -- module A --
>> > class A {
>> >   func foo() {}
>> > }
>> >
>> > -- module B --
>> > protocol Foo {
>> >   func foo()
>> > }
>> > extension A: Foo {}
>> let c = A()
>> I’d say that you have two functions here:
>> A.foo() and A.Foo.foo()
> No. Now (i.e. within module B) A conforms to Foo, using the already existing function.
>> Note that A.foo() was never intended to be used as an implementation
>> for protocol Foo, thus why should you be able to see it as such? That
>> imo is a bug in the language. Its not flexibility, it’s dangerous.
> I disagree, this is the great thing about Swift.
> It's exactly in the middle between Go's "everything is considered to implement a protocol if it happens to provide the right methods" and C++/younameit's "you have to know everything in advance and people are screwed if the library does not use the right protocols" style.
> You can add protocol conformance to classes you don't control, but you have to explicitly declare this conformance.
> I think this is exactly the right approach.
> -- 
> Martin

More information about the swift-evolution mailing list