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
> <[email protected]> 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
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
