<div dir="ltr"><div class="gmail_default" style="font-family:georgia,serif">I know what you mean at the beginning. However, as your example shows, the warning means nothing if it really happens. </div><div class="gmail_default" style="font-family:georgia,serif"><br></div><div class="gmail_default" style="font-family:georgia,serif">Because you cannot solve the problem by revising your own code. You definitely have to change the protocols. If you have no way to change the protocols, you will have to drop either of them. </div><div class="gmail_default" style="font-family:georgia,serif"><br></div><div class="gmail_default" style="font-family:georgia,serif">My point is that it is the protocols' programmer who should take care of it, not you. Or if you write the protocols, you should avoid this at the beginning.</div><div class="gmail_default" style="font-family:georgia,serif"><br></div><div class="gmail_default" style="font-family:georgia,serif">zhaoxin</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Jan 9, 2016 at 11:09 AM, Brent Royal-Gordon via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> I don’t really get what you are driving at.<br>
<br>
</span>The point is that, although `A` and `B` both require properties with the same name, they expect different semantics from that property. Let's maybe give these more concrete names so you can understand the idea:<br>
<br>
protocol Marriageable {<br>
var ring: String? { get set } // File name of image of this person's wedding ring.<br>
}<br>
protocol CallReceivable {<br>
var ring: String? { get set } // File name of ringtone to be used for this person.<br>
}<br>
<br>
struct Person: Marriageable, CallReceivable {<br>
var ring: String?<br>
}<br>
<br>
Of course a person is marriageable and can this have "a ring", and of course you can also receive a call from them and they can thus have "a ring". But in reality, the "ring" that satisfies one of these things will not work for the other. If your best friend gets married and you add an image of the ring, then the next time your friend calls you, the phone ringing screen will try to play a JPEG as an MP3.<br>
<br>
The "ring" example is, of course, slightly contrived, but I'm sure you can imagine a similar problem with real names, where you end up using the same term for two different and incompatible things.<br>
<br>
What the OP is basically asking is, when Swift sees the same type conforming to Marriageable and CallReceivable, should it optimistically assume that the `ring` properties they both require are compatible and allow the code to pass through without comment? Or should it pessimistically assume that the `ring` properties are incompatible and emit a warning or error about them?<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Brent Royal-Gordon<br>
Architechies<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">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>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div><br>Owen Zhao<br></div></div></div>
</div>