<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 9. Jul 2017, at 06:06, Xiaodi Wu via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">On Sat, Jul 8, 2017 at 10:52 PM, Jonathan Hull <span dir="ltr" class=""><<a href="mailto:jhull@gbis.com" target="_blank" class="">jhull@gbis.com</a>></span> wrote:<br class=""><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class="">Do you know why it was never brought to a vote? </div></blockquote><div class=""><br class=""></div><div class="">If I had to guess, it would be because the core team decided it's not in scope.</div></div></div></div></div></blockquote><div><br class=""></div><div>That’s pretty-much what happened. I wanted to allow nesting arbitrary types in protocols (e.g. FloatingPoint.Sign) and vice-versa (e.g. UITableView.Delegate). Wasn’t in scope.</div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class=""><br class=""></div><div class="">As an aside not central to your question and not directed to you specifically: There aren't votes in the evolution process; there are community and core team reviews. The purpose, afaik, isn't to count the number of replies that say "+1" or "-1."</div><div class=""> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><div class=""></div><div class="">I seem to remember us having a pretty good consensus. I think we decided to punt on nested generics by just not allowing nesting in them yet (which would be compatible since that is what happens now too). Then we would have a second proposal to deal with generics/associated more carefully.</div></div></blockquote><div class=""><br class=""></div><div class=""> I'm not aware of any proposal text that punts on nested generics.</div></div></div></div></div></blockquote></div><div><br class=""></div><div>Capturing generic type parameters between nested types works already. We lack the expressive ability to capture associated types between nested protocols (we would need generalised existentials). Capturing between generic types and associated types was controversial (and… yeah, that not exactly frictionless boundary between generic protocols and structural types is usually most people’s biggest problem with Swift’s generics).</div><div><br class=""></div><div><div>Consider MyObject<T>.Delegate:</div><div><br class=""></div><div>- Should we create a new protocol for every type T (allowing one object to conform to both MyObject<Int>.Delegate and MyObject<String>.Delegate)?, or</div><div>- Should there be one MyObject.Delegate protocol with an implicit associated-type “T”? e.g. "MyObject.Delegate where T == Int”. That would require "generalised existentials”.</div><div><br class=""></div><div>So yeah, the proposal didn’t include capturing between nested protocols and types.</div><div><br class=""></div><div>Also, I had some trouble nailing down the rules for when a nested type should be imported in to a conformer’s namespace. For example, you probably want Double.Sign to be an alias for FloatingPoint.Sign, but in general that might not always be true - especially if nested types and protocols can be added in extensions, things could get cluttered rather quickly. We don’t really have any formally-specified rules for unqualified lookup to take guidance from, either. In any case I think we should use the new protocol typealias lookup rules that appear to have popped up in Swift 3.2 - i.e. that typealiases inside the protocol body get inherited, but typealiases inside extensions don’t.</div><div><br class=""></div><div>Long-term I really think we need to write down our rules for unqualified lookup. Something equivalent to this: <a href="http://en.cppreference.com/w/cpp/language/unqualified_lookup" class="">http://en.cppreference.com/w/cpp/language/unqualified_lookup</a></div><div><br class=""></div><div>- Karl</div><div><br class=""></div><div><br class=""></div><div><br class=""></div><div><br class=""></div><div><br class=""></div><div class=""><br class=""></div></div></body></html>