[Accepted] SE-0309: Unlock Existentials for All Protocols

The review discussion for SE-0309, Unlock Existentials for All Protocols, has concluded. The proposal has been accepted. There was a lot of enthusiasm for removing the infamous "protocol can only be used as a generic constraint because it has Self or associated type requirements" restriction, and the Core Team agrees that at this point in Swift's development, it serves no technical purpose, and the problems it causes are worse than the ones it tries to avoid. The Core Team also acknowledges that this proposal by itself does not solve all the problems with existentials in Swift, but that it is important progress in unblocking further improvements to generics and existentials going forward.

Much of the discussion referenced the document "Improving the UI of Generics", and particularly the proposed syntax any Protocol for existentials. One of the issues with existentials in Swift is that, even though they are spelled by the protocol name alone, they don't really behave like a type conforming to the protocol in many situations. By removing the "Self or associated type constraints" restrictions, there will be even more divergence, because as the proposal notes, API on the protocol with contravariant Self or associated type arguments will be unavailable on existentials of the type. Many people noted that this might be an opportunity to introduce an explicit syntax for existentials, such as any Protocol, either as a preferred alternative to Protocol, or as a requirement for existentials of protocols that have Self or associated type requirements. On this topic, the Core Team does not think this is the point to introduce a new existential syntax. We see eliminating distinctions between protocols with and without associated types as an important goal of this proposal, and imposing different syntax rules for different existentials would run counter to that goal. 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.

Thanks to everyone who participated in the review!

65 Likes

Any chance for it to be released in 5.5?

6 Likes

Could we add the terms existential/existential value, existential type and protocol type mentioned in the proposal to the type spec?

5 Likes

@Joe_Groff just a tiny theoretical question for clarification: Does the acceptance of the proposal as-is leave us room to introduce the any syntax in the future at all? :thinking:

Yes – this is implied by:

14 Likes

Thank you for explicit clarification on that, I really appreciate it.

We are in Swift 5.3 Do we really need to change syntax as implied just because of essentials ?

IMHO l think syntax changes should be avoided. We should stick with the “where” clause to infer whatever is necessary.

Looking into the future the “any protocol “ would open room for tons of bugs and abuse of the syntax. Just thinking towards the of “Any” usage at moment and being cautious about the introduction of another one on the protocol

Did you mean existentials?

The proposal doesn't introduce any syntactical changes; the any Protocol syntax is discussed solely as a future direction.

There has already been a lot of discussion about the any syntax in the review thread and in a thread discussing syntax changes for existentials. Perhaps you should check those out.

Terms of Service

Privacy Policy

Cookie Policy