Extensions in Swift aren&#39;t a first-class entity; they have no name and no representation in the type system. If an extension to A does something, then A does something. If A conforms to P, then A.foo is the implementation of P.foo.<br><div class="gmail_quote"><div dir="ltr">On Thu, Sep 22, 2016 at 11:06 Marinus van der Lugt via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">That does not seem right to me. A does not implement any protocol.<br>
The extension of A implements a protocol thus foo() should not be seen as part of the protocol at all.<br>
<br>
So far, I have always extended a class when adding protocol compliance. I.e. it is always clear<br>
<br>
I.e.<br>
<br>
protocol P {<br>
func foo()<br>
}<br>
<br>
class A {<br>
 fun foo() {} // Should not be regarded as implementation of P<br>
}<br>
<br>
extension A: P {<br>
 func foo() {} // This is the implementation of P<br>
}<br>
<br>
&gt;<br>
&gt; On 22 Sep 2016, at 11:28, Martin Waitz via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt; wrote:<br>
&gt;<br>
&gt; Hi,<br>
&gt;<br>
&gt; isn&#39;t it perfectly fine to conform to multiple unrelated protocols which both require the same member?<br>
&gt; Or to declare protocol conformance in some unrelated module?<br>
&gt;<br>
&gt; Am 2016-09-22 07:15, schrieb Karl via swift-evolution:<br>
&gt;&gt; I would like to make it a requirement if not inside a protocol<br>
&gt;&gt; extension which declares a conformance, and actually build the<br>
&gt;&gt; protocol name in to the member in an ABI-breaking way.<br>
&gt;<br>
&gt; IMO, this is much too restrictive.<br>
&gt; When we force the protocol name into the member, we make it impossible to conform to multiple protocols.<br>
&gt; Well ok, we could create alias names for all protocols.<br>
&gt; But often you don&#39;t know which protocols to conform to when you compile your module!<br>
&gt;<br>
&gt; What about:<br>
&gt;<br>
&gt; -- module A --<br>
&gt; class A {<br>
&gt;   func foo() {}<br>
&gt; }<br>
&gt;<br>
&gt; -- module B --<br>
&gt; protocol Foo {<br>
&gt;   func foo()<br>
&gt; }<br>
&gt; extension A: Foo {}<br>
&gt;<br>
&gt; What is your ABI name for A.foo()?<br>
&gt;<br>
&gt; Let&#39;s keep it simple!<br>
&gt; If a simple warning about unrelated methods in a protocol conformance extension solves 95% of our problem,<br>
&gt; then we shouldn&#39;t overengineer and throw away all our flexibility just to be 100% explicit about which protocol uses which members.<br>
&gt;<br>
&gt; --<br>
&gt; Martin<br>
&gt; _______________________________________________<br>
&gt; swift-evolution mailing list<br>
&gt; <a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
&gt; <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
<br>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</blockquote></div>