<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=""><br class=""><div><blockquote type="cite" class=""><div class="">On Feb 5, 2017, at 10:06 AM, Karl <<a href="mailto:notifications@github.com" class="">notifications@github.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><p class=""><a href="https://github.com/slavapestov" class="user-mention">@slavapestov</a> I can't reply to your comments directly so will have do batch them here:</p>
<blockquote class=""><p class="">With the current implementation of name lookup, qualified and unqualified lookup will find the nominal type as a member of the conforming type. In Swift 3 there was a bug where unqualified name lookup didn't find a typealias, but this is fixed now.</p>
</blockquote><p class="">I think the nicest rule would be that, if the nested type is used by a protocol requirement, it <em class="">does</em> actually get imported in to the namespace of the conforming type (the compiler would generate a hidden typealias). That way, you would actually get something called <code class="">Float.Sign</code> and <code class="">Double.Sign</code>, could refer to them as just <code class="">Sign</code> from extensions, etc.</p><p class="">For everything else (i.e. nested types which are not used by requirements and do not capture associated types), they likely have nothing to do with the conforming type. It makes sense then, that everybody should have to spell it as <code class="">RandomAccessCollection.Concurrent<Array<Int>></code> and not just <code class="">.Concurrent</code>, regardless of whether or not the current context conforms to <code class="">RandomAccessCollection</code>.</p><div class=""><br class=""></div></div></blockquote><br class="">This sounds too complex — the unqualified lookup implementation is tricky enough as-is, so let’s stick with the simplest rule that makes sense: unqualified lookup inside a concrete type will find all members (requirements, as well as nested types) of any protocol that the concrete type conforms to.</div><div><br class=""></div><div>Slava<br class=""><blockquote type="cite" class=""><div class=""><p class="">We leave the door open for capturing types (when they are possible) to be spelled differently, so you could maybe just write <code class="">let myVar: Concurrent</code> inside an extension of <code class="">Array<Int></code> in order to get a <code class="">RandomAccessCollection.Concurrent where Collection == Array<Int></code>.</p>
<blockquote class=""><p class="">At the very least, it is a separate proposal :)</p>
</blockquote><p class="">I'm worried that if we leave it, there may be ABI decisions we take now which make it unpalatable later. Even if this part of the proposal can't be implemented right away, it'd be nice to keep it; especially since you can have generic NSObject subclasses, and it's reasonable to want to have nested delegate protocols inside of them.</p><div class=""><br class=""></div></div></blockquote><div><br class=""></div>Once we figure out the right semantics for protocols inside generic types, we should be able to implement them without disturbing ABI. Again, speaking as someone who is likely to end up implementing this proposal were it to be accepted, it makes sense to tackle the non-generic protocol case first, even if the proposal has generic protocols.</div><div><br class=""></div><div>Also, if we allow this:</div><div><br class=""></div><div>struct G<T> {</div><div> protocol P {</div><div> func foo() -> T</div><div> }</div><div>}</div><div><br class=""></div><div>Why not go all the way and allow this?</div><div><br class=""></div><div>protocol P<T> {</div><div> func foo() -> T</div><div>}</div><div><br class=""></div><div>They’re essentially equivalent.</div><div><br class=""></div><div>But yeah, that’s definitely a separate proposal.</div><div><br class=""></div><div>Slava</div><div><br class=""><blockquote type="cite" class=""><div class=""><p style="font-size:small;-webkit-text-size-adjust:none;color:#666;" class="">—<br class="">You are receiving this because you were mentioned.<br class="">Reply to this email directly, <a href="https://github.com/apple/swift-evolution/pull/552#issuecomment-277536960" class="">view it on GitHub</a>, or <a href="https://github.com/notifications/unsubscribe-auth/AAEDtgNnQ9dOU4Rtiw_4VwY996cICYqCks5rZg-egaJpZM4KqNwF" class="">mute the thread</a>.<img alt="" height="1" src="https://github.com/notifications/beacon/AAEDtjXUmaa3WRVaU4J3r5Nrx6SOn4E6ks5rZg-egaJpZM4KqNwF.gif" width="1" class=""></p>
<div itemscope="" itemtype="http://schema.org/EmailMessage" class="">
<div itemprop="action" itemscope="" itemtype="http://schema.org/ViewAction" class="">
<link itemprop="url" href="https://github.com/apple/swift-evolution/pull/552#issuecomment-277536960" class="">
<meta itemprop="name" content="View Pull Request" class="">
</div>
<meta itemprop="description" content="View this Pull Request on GitHub" class="">
</div>
<script type="application/json" data-scope="inboxmarkup" class="">{"api_version":"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name":"GitHub"},"entity":{"external_key":"github/apple/swift-evolution","title":"apple/swift-evolution","subtitle":"GitHub repository","main_image_url":"<a href="https://cloud.githubusercontent.com/assets/143418/17495839/a5054eac-5d88-11e6-95fc-7290892c7bb5.png" class="">https://cloud.githubusercontent.com/assets/143418/17495839/a5054eac-5d88-11e6-95fc-7290892c7bb5.png</a>","avatar_image_url":"<a href="https://cloud.githubusercontent.com/assets/143418/15842166/7c72db34-2c0b-11e6-9aed-b52498112777.png" class="">https://cloud.githubusercontent.com/assets/143418/15842166/7c72db34-2c0b-11e6-9aed-b52498112777.png</a>","action":{"name":"Open in GitHub","url":"<a href="https://github.com/apple/swift-evolution" class="">https://github.com/apple/swift-evolution</a>"}},"updates":{"snippets":[{"icon":"PERSON","message":"@karwa in #552: @slavapestov I can't reply to your comments directly so will have do batch them here:\r\n\r\n\u003e With the current implementation of name lookup, qualified and unqualified lookup will find the nominal type as a member of the conforming type. In Swift 3 there was a bug where unqualified name lookup didn't find a typealias, but this is fixed now.\r\n\r\nI think the nicest rule would be that, if the nested type is used by a protocol requirement, it *does* actually get imported in to the namespace of the conforming type (the compiler would generate a hidden typealias). That way, you would actually get something called `Float.Sign` and `Double.Sign`, could refer to them as just `Sign` from extensions, etc.\r\n\r\nFor everything else (i.e. nested types which are not used by requirements and do not capture associated types), they likely have nothing to do with the conforming type. It makes sense then, that everybody should have to spell it as `RandomAccessCollection.Concurrent\u003cArray\u003cInt\u003e\u003e` and not just `.Concurrent`, regardless of whether or not the current context conforms to `RandomAccessCollection`.\r\n\r\nWe leave the door open for capturing types (when they are possible) to be spelled differently, so you could maybe just write `let myVar: Concurrent` inside an extension of `Array\u003cInt\u003e` in order to get a `RandomAccessCollection.Concurrent where Collection == Array\u003cInt\u003e`.\r\n\r\n\u003e At the very least, it is a separate proposal :)\r\n\r\nI'm worried that if we leave it, there may be ABI decisions we take now which make it unpalatable later. Even if this part of the proposal can't be implemented right away, it'd be nice to keep it; especially since you can have generic NSObject subclasses, and it's reasonable to want to have nested delegate protocols inside of them."}],"action":{"name":"View Pull Request","url":"<a href="https://github.com/apple/swift-evolution/pull/552#issuecomment-277536960" class="">https://github.com/apple/swift-evolution/pull/552#issuecomment-277536960</a>"}}}</script></div></blockquote></div><br class=""></body></html>