Pitch: Allow Protocols to be Nested in Non-Generic Contexts

Evolution Pitches
22

Understood. But I also think we can disable satisfying associatedtype requirement with nested protocol in Swift 5.9 or later, since this is a new feature which will be introduced after SE-0335 is introduced.
I believe source break creates a bit difficult situation, consider the following case.

// Swift 5
public protocol P {
     associatedtype Q
}
public struct A: P {
    // this is now satisfying associatedtype requirement
    protocol Q {}
}

// usage as constraint
extension B: A.Q { /* ... */ }
// usage as type
let value: A.Q = /* ... */

In Swift 6, as Q is no longer usable as a type, you have to change the type into like this.

public struct A: P {
    public typealias Q = any _Q
    public protocol _Q {}
}

However, making such a change is API-breaking, because the usage of A.Q as constraint is no longer possible. While --enable-upcoming-feature ExistentialAny will expose such risks, I also think avoiding such scenario from the beginning of nested protocol introduction is worth considering.

3 Likes