<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">In Eiffel you would have to rename at least one of the conflicting members in the implementing class to distinguish the cases there.<div class="">When called through one of the protocols the correct renamed member would be used, i.e. (translated to pseudo-Swift):</div><div class=""><br class=""></div><div class=""><b class="">protocol</b> Marriageable {<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span><b class="">var</b> ring: String? { <b class="">get</b> <b class="">set</b> }<span class="Apple-tab-span" style="white-space:pre"> </span>// File name of image of this person's wedding ring.<br class="">}<br class=""><br class=""></div><div class=""><b class="">protocol</b> CallReceivable {<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span><b class="">var</b> ring: String? { <b class="">get</b> <b class="">set</b> } <span class="Apple-tab-span" style="white-space:pre"> </span>// File name of ringtone to be used for this person.<br class="">}<br class=""><br class="">// In this example I choose to rename both<br class=""><b class="">struct</b> Person: Marriageable <b class="">rename</b> ring <b class="">to</b> ringImage, CallReceivable <b class="">rename</b> ring <b class="">to</b> ringTone {<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span><b class="">var</b> ringImage: String?</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span><b class="">var</b> ringTone: String?<br class="">}</div><div class=""><br class=""></div><div class=""><b class="">let</b> friend: Person = ...</div><div class=""><b class="">let</b> m: Marriageable = friend</div><div class=""><b class="">let</b> callee: CallReceivable = friend</div><div class=""><br class=""></div><div class="">friend.ring <span class="Apple-tab-span" style="white-space:pre"> </span>// type error (the Person type only has vars ringImage and ringTone)</div><div class="">friend.ringImage <span class="Apple-tab-span" style="white-space:pre"> </span>// file name of image of wedding ring</div><div class="">friend.ringTone <span class="Apple-tab-span" style="white-space:pre"> </span>// file name of ring tone</div><div class="">m.ring <span class="Apple-tab-span" style="white-space:pre"> </span>// result of friend.ringImage because of rename</div><div class="">callee.ring <span class="Apple-tab-span" style="white-space:pre"> </span>// result of friend.ringTone because of rename</div><div class=""><br class=""></div><div class="">This always does the right thing and solves the problem nicely.</div><div class=""><br class=""></div><div class="">-Thorsten</div><div class=""><br class=""></div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">Am 09.01.2016 um 04:09 schrieb Brent Royal-Gordon via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>>:</div><br class="Apple-interchange-newline"><div class=""><div class=""><blockquote type="cite" class="">I don’t really get what you are driving at.<br class=""></blockquote><br class="">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 class=""><br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>protocol Marriageable {<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span><span class="Apple-tab-span" style="white-space:pre"> </span>var ring: String? { get set }<span class="Apple-tab-span" style="white-space:pre"> </span>// File name of image of this person's wedding ring.<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>}<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>protocol CallReceivable {<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span><span class="Apple-tab-span" style="white-space:pre"> </span>var ring: String? { get set } <span class="Apple-tab-span" style="white-space:pre"> </span>// File name of ringtone to be used for this person.<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>}<br class=""><br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>struct Person: Marriageable, CallReceivable {<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span><span class="Apple-tab-span" style="white-space:pre"> </span>var ring: String?<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>}<br class=""><br class="">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 class=""><br class="">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 class=""><br class="">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 class=""><br class="">-- <br class="">Brent Royal-Gordon<br class="">Architechies<br class=""><br class="">_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></div></blockquote></div><br class=""></div></body></html>