How deeply will the compiler infer the types behind parameterized protocols?

[YOCKOW]

@CrystDragon

Inside the extensions of Container, the identifier Content only carry one constraint: Content: P. It would be super confusing for me if the compiler allow Content to have the constraint Content: Q inside the if case clause:

I agree that changing Content constraints in if-clause would be confusing.
So I'm noticing that this can be reduced to an issue about intersection types.

Current Swift allows intersection types only for protocol-constrained types/protocol composition:

protocol P1 {}
protocol P2 {}
class C1 {}

let _: any P1 & P2 & C1 // ✅ Allowed

func f<T>(_: T) {
  let _: T & any P1 // ⛔️ Not Allowed
  // error: non-protocol, non-class type 'T' cannot be used within a protocol-constrained type
}

If we could allow T & any P1 (at least internally), Test Case #3 might be compiled:

extension Container {
  func testX() {
    if case let qSelf as any QContainer<Content> = self {
      // Then, `qSelf.content` could be inferred as `Content & any Q`.
      print("Value of `qa` is: \(qSelf.content.qa)") // Would come along.
    }
  }
}