I like this approach, @implements is nice, clear, concise and handles many cases.<div><br></div><div>It will require your proposal, or similar, to be universally applicable though, but I expect it will pass<span></span>: Naming Functions with Argument Labels.</div><div><br></div><div>Many Cocoa delegate protocols will have similar function names, ie. collectionView(...).<br><br>On Thursday, 14 January 2016, Joe Groff via swift-evolution &lt;<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;swift-evolution@swift.org&#39;);" target="_blank">swift-evolution@swift.org</a>&gt; wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
&gt; On Jan 7, 2016, at 2:18 AM, Grzegorz Leszek via swift-evolution &lt;<a>swift-evolution@swift.org</a>&gt; wrote:<br>
&gt;<br>
&gt; I suggest compile warning if one classes/structs/enums implements<br>
&gt; protocols with the same name.<br>
&gt; It could lead to confusions, when methods of those protocols will mean<br>
&gt; different things.<br>
&gt; It will force to implement parent protocol with shared methods or<br>
&gt; change method in one of the protocols.<br>
&gt; Below is an example.<br>
&gt; Regards,<br>
&gt; Greg<br>
&gt;<br>
&gt; //💍<br>
&gt; protocol A {<br>
&gt;  var ring: String { get }<br>
&gt; }<br>
&gt;<br>
&gt; //🔔<br>
&gt; protocol B {<br>
&gt;  var ring: String { get set }<br>
&gt; }<br>
&gt;<br>
&gt; class X: A, B {<br>
&gt;  var ring: String {<br>
&gt;    get {<br>
&gt;      return &quot;💍&quot;<br>
&gt;    }<br>
&gt;    set {<br>
&gt;      self.ring = newValue<br>
&gt;    }<br>
&gt;  }<br>
&gt; }<br>
&gt; let x = X()<br>
&gt; let somewhereInTheProject = &quot;\(x.ring) the bell&quot;<br>
&gt; x.ring = &quot;🔔&quot; // ERROR!<br>
<br>
Swift&#39;s protocol conformance model doesn&#39;t rely on the name of the member matching the name of the requirement it satisfies. One possibility here is to introduce an attribute to explicitly declare what protocol requirement(s) a member is intended to satisfy:<br>
<br>
class X: A, B {<br>
  @implements(A.ring)<br>
  var weddingRing: String<br>
<br>
  @implements(B.ring)<br>
  var ringtone: String<br>
}<br>
<br>
As other noted, protocols with same-named requirements but different semantics are rare in practice, and it&#39;s occasionally useful to intentionally overlap requirements (I believe the CollectionType hierarchy does this in places), so the current behavior feels like a reasonable default to me. I can see value in requiring it to be explicit though.<br>
<br>
-Joe<br>
<br>
_______________________________________________<br>
swift-evolution mailing list<br>
<a>swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</blockquote>
</div>