Can the compiler be more helpful when we need to explicitly, dynamically specialize existentials?

This was supposed to be a case where a requirement contains associated type that was erased by existential.

protocol P {
    associatedtype A
    func takeA(_ a: A)
}

struct P1: P {
    func takeA(_ a: String) { ... }
}

for anyP in anyPs {
    switch anyP {
        case let p1 as P1:
            p1.takeA("hello")
        default:
            fatalError()
    }
}

At some point the existential needs to be dynamically specialized in order to use the member. In certain cases this is just unavoidable.


I was confident that my protocol cannot be turned into enum. So I moved on, to search for "sealed protocols" you mentioned and during browsing I stumbled on Sealed protocols - #63 by Joe_Groff and it hit me. I'll need to explore this more. But I can imagine this could easily turn into a topic where enums are lacking features that protocols provide with associated types (without lots of boilerplate, payload and awful ergonomics). Anyways, using just internal protocols with just definite set of conforming types over enum may be formally correct and naturally ideal, not worthy to trade for enums with exhaustive switching.

Regarding "sealed protocols", they attempt to solve a much more complex problem, like conceptually with access control that may even clash with Scoped Conformances, and doesn't even have exhaustive switching as a priority. Exhaustive switching over a sealed protocol is more like an opportunity there.


Now the question is if exhaustive switching over a "sealed" protocol should be a thing, or it is ill, or there may be something better. If the exhaustive switch could eventually be the problem solver, is it worthy to discover it on internal ("implicitly sealed") protocols as a starter?