[swift-evolution] Mark protocol methods with their protocol

[Marinus van der Lugt]

That does not seem right to me. A does not implement any protocol.
The extension of A implements a protocol thus foo() should not be seen as part of the protocol at all.

So far, I have always extended a class when adding protocol compliance. I.e. it is always clear

I.e.

protocol P {
func foo()
}

class A {
 fun foo() {} // Should not be regarded as implementation of P
}

extension A: P {
 func foo() {} // This is the implementation of P
}

> 
> On 22 Sep 2016, at 11:28, Martin Waitz via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Hi,
> 
> isn't it perfectly fine to conform to multiple unrelated protocols which both require the same member?
> Or to declare protocol conformance in some unrelated module?
> 
> Am 2016-09-22 07:15, schrieb Karl via swift-evolution:
>> I would like to make it a requirement if not inside a protocol
>> extension which declares a conformance, and actually build the
>> protocol name in to the member in an ABI-breaking way.
> 
> IMO, this is much too restrictive.
> When we force the protocol name into the member, we make it impossible to conform to multiple protocols.
> Well ok, we could create alias names for all protocols.
> But often you don't know which protocols to conform to when you compile your module!
> 
> What about:
> 
> -- module A --
> class A {
>   func foo() {}
> }
> 
> -- module B --
> protocol Foo {
>   func foo()
> }
> extension A: Foo {}
> 
> What is your ABI name for A.foo()?
> 
> Let's keep it simple!
> If a simple warning about unrelated methods in a protocol conformance extension solves 95% of our problem,
> then we shouldn't overengineer and throw away all our flexibility just to be 100% explicit about which protocol uses which members.
> 
> -- 
> Martin
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution