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!
