Strong +1 on this.
Oh yes. This feature has been highly requested since the earliest days of Swift, and has always been on the "someday we'll get to this" checklist.
It does now that we've worked out the whole story of generics ergonomics, simplifying generics (e.g., with some Collection<String>) and extending support for existentials via SE-0309.
I've been involved with the design of this feature, so I'm not unbiased here.
I do have one request. SE-0309 specifies that we cannot call a member of an existential value if the result type of that member uses any of the associated types in an invariant position. That prevents code like this from working:
extension Collection {
func doSomething() -> some Collection<Element> { ... }
}
func test(strings: any Collection<String>) {
let otherStrings = strings.doSomething() // error: result type uses Element in an invariant position
}
We don't have to prevent this, and indeed we want this call to succeed and produce an any Collection<String>. I believe the change is straightforward, allowing same-type requirements on primary associated types and inferring an existential where those primary associated types are bound appropriately. However, I'd prefer that this change be documented as part of this proposal, because I'd like any expansion of the expressivity of existentials to coincide with a change to this rule set out by SE-0309.
Doug