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@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@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to