> On 9. Jul 2017, at 06:06, Xiaodi Wu via swift-evolution > <[email protected]> wrote: > > On Sat, Jul 8, 2017 at 10:52 PM, Jonathan Hull <[email protected] > <mailto:[email protected]>> wrote: > Do you know why it was never brought to a vote? > > If I had to guess, it would be because the core team decided it's not in > scope.
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. > > 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." > > 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. > > I'm not aware of any proposal text that punts on nested generics. 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). Consider MyObject<T>.Delegate: - 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 - 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”. So yeah, the proposal didn’t include capturing between nested protocols and types. 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. Long-term I really think we need to write down our rules for unqualified lookup. Something equivalent to this: http://en.cppreference.com/w/cpp/language/unqualified_lookup <http://en.cppreference.com/w/cpp/language/unqualified_lookup> - Karl
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
