Lifting the "Self or associated type" constraint on existentials

I do agree that we should allow implicit opening of existentials when they're passed as unique generic arguments to a generic function; I agree that will likely cover the majority of places you might want "self-conformance". I don't think banning existentials as function arguments is necessary, or really possible to begin with, since existential types still can be bound to generic type arguments. To work with an Array<Protocol>, Array's generic methods need to be able to work in terms of the Protocol type without boxing and unboxing in the unspecialized case. If existentials have to be syntactically decorated, and we had some Protocol syntax for generic arguments in addition to opaque generic returns, I don't think you need to go out of your way to ban existential arguments, since someone writing foo(x: Protocol) would at that point need to decide whether they mean foo(x: some Protocol) or foo(x: any Protocol).

15 Likes