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 <<a href="javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org');" target="_blank">swift-evolution@swift.org</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
> On Jan 7, 2016, at 2:18 AM, Grzegorz Leszek via swift-evolution <<a>swift-evolution@swift.org</a>> wrote:<br>
><br>
> I suggest compile warning if one classes/structs/enums implements<br>
> protocols with the same name.<br>
> It could lead to confusions, when methods of those protocols will mean<br>
> different things.<br>
> It will force to implement parent protocol with shared methods or<br>
> change method in one of the protocols.<br>
> Below is an example.<br>
> Regards,<br>
> Greg<br>
><br>
> //💍<br>
> protocol A {<br>
> var ring: String { get }<br>
> }<br>
><br>
> //🔔<br>
> protocol B {<br>
> var ring: String { get set }<br>
> }<br>
><br>
> class X: A, B {<br>
> var ring: String {<br>
> get {<br>
> return "💍"<br>
> }<br>
> set {<br>
> self.ring = newValue<br>
> }<br>
> }<br>
> }<br>
> let x = X()<br>
> let somewhereInTheProject = "\(x.ring) the bell"<br>
> x.ring = "🔔" // ERROR!<br>
<br>
Swift's protocol conformance model doesn'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'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>