<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On May 26, 2016, at 12:03 PM, Matthew Johnson <<a href="mailto:matthew@anandabits.com" class="">matthew@anandabits.com</a>> wrote:</div><div class=""><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div class=""><br class=""></div><div class="">Austin, this brings to mind the question of how you will handle conflicts if the type defines an instance member with the same name as the asociatedtype. This should be uncommon due to capitalization conventions but is still a possibility.</div></div></div></blockquote><div><br class=""></div><div>This is a really good point. I'm tempted at this point to punt on this potential issue, the same way we don't handle two protocols with associated types that have the same name :).</div><div><br class=""></div><div>This problem should be mentioned, but like you said code that conforms to conventional Swift style shouldn't run into this problem. For example, I wouldn't expect Apple frameworks to be able to cause this issue in user code, since they are pretty scrupulous about naming. It may simply be easiest to ask users to rename their members if it becomes a problem. (Any alternate suggestions are, as always, welcome too.)</div><div><br class=""></div><div>Austin</div></div></body></html>