SE-0309: Unlock existential types for all protocols

[Moximillian (Mox)]

First of all, although not directly part of SE-0309, the deeper discussion about existentials (and opaque types) has been extremely interesting to me, as it has views from both swift insiders and from outside. And it is relevant for the future features for existential, which were also highlighted in SE-0309. So thanks to all who have contributed.

@Joe_Groff

@Dmitriy_Ignatyev

In first case instance of SomeProtocol can have different underlying types. In second case Type is known at compile time.

Neither of these statements is always true. If you pass a value of known static type into an existential, then the compiler can see that and still specialize the function based on the type going in. Similarly, if you call the generic function with a dynamic type, the compiler does not necessarily know what that type is, and may not be able to specialize.

@Joe_Groff

There is an "existential specializer" pass that turns some functions with existential arguments into their generic forms, which allows generic specialization passes to further optimize them. You could maybe use @inline(never) to suppress specialization, but there still isn't a fully designed and developed suite of attributes for controlling optimizer behavior.

Now this is interesting. Since it's the compiler, not the developer who makes the decisions about performance characteristics (speed vs code size, for example), then to me it's actually no longer important to advocate for "correct" choice to be made regarding generics vs. existentials, which for me was one important reason for "any P"... Especially now that SE-0309 has been accepted.

So I guess where "any P" (as one of the possible solutions), would be still be potentially relevant are the places where:

1. you have to use generics, existentials wouldn't simply work. I guess SE-0309 implementation already has some error messages related to this, nudging you to the right direction?
2. you have to use existentials, generics simply wouldn't work (the obvious one being heterogenous collections). Is there a way to better inform developers about this?
3. future new features around existentials, and how to make syntax for those new features more understandable so that people get them right more often than wrong. One key place in my mind would be extension syntax for describing existential conformance to its protocol, which might be needed for protocols with associated types... if such thing makes sense:

extension any SomeProto: SomeProto { ... }

In a way I now find it understandable that the core team wants to defer the syntax change decisions to the proposals where new features would be introduced to existentials and then discuss the syntax in conjuction to those changes:

@Joe_Groff

We also know that the existential syntax will have to be expanded to allow for where constraints on associated types, and we don't want to prematurely introduce a new existential syntax without knowing how that new syntax will accommodate other necessary extensions.

The current situation is not perfect, but at least we got rid of the overly eager firewalls in SE-0309