Nested types in protocols (and nesting protocols in types)

Evolution Pitches
54

I'm not sure what you mean by a "fully-qualified way"? Generic parameters can't be fully-qualified; they're just their name. (Which is presumably why in Swift 6, it's being disallowed for nested types to shadow outer generic outer parameters with their own generic parameters.)

Swift today already gives meaning to X.Y when X is a generic type; it implies type parameter inference:

struct X<T> {
    struct Y {
        init(_ t: T) {}
    }
}

// Totally valid syntax that means the type of x is `X<Int>.Y`
let x: X.Y = X.Y(5)

If we allowed nested types that didn't capture outer context, the only way to know whether X<Int>.Y or X.Y was intended here would be to check every member of Y to see whether it references T, which as @Slava_Pestov mentioned above should be avoided, or to invent a new syntax to distinguish it.

1 Like