[swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol<P1, P2> syntax with Any<P1, P2>
jordan_rose at apple.com
Wed May 25 12:45:21 CDT 2016
> On May 25, 2016, at 10:43, Matthew Johnson <matthew at anandabits.com> wrote:
> Sent from my iPad
>> On May 25, 2016, at 12:10 PM, Jordan Rose via swift-evolution <swift-evolution at swift.org> wrote:
>>>> On May 25, 2016, at 05:27, Brent Royal-Gordon via swift-evolution <swift-evolution at swift.org> wrote:
>>>> AFAIK an existential type is a type T with type parameters that are still abstract (see for example https://en.wikipedia.org/wiki/Type_system#Existential_types), i.e. have not been assigned concrete values.
>>> My understanding is that, in Swift, the instance used to store something whose concrete type is unknown (i.e. is still abstract), but which is known to conform to some protocol, is called an "existential". Protocols with associated values cannot be packed into normal existentials because, even though we know that the concrete type conforms to some protocol, the associated types represent additional unknowns, and Swift cannot be sure how to translate uses of those unknown types into callable members. Hence, protocols with associated types are sometimes called "non-existential".
>>> If I am misusing the terminology in this area, please understand that that's what I mean when I use that word.
>> We’re not consistent about it, but an “existential value” is a value with protocol or protocol composition type. My mnemonic for this is that all we know is that certain operations exist (unlike a generic value, where we also have access to the type). John could explain it more formally. We sometimes use “existentials” as a (noun) shorthand for “existential value”.
>> In the compiler source, all protocols and protocol compositions are referred to as “existential types”, whether they have associated types or not. Again, a protocol asserts the existence (and semantics) of various operations, but nothing else about the conforming type. (Except perhaps that it’s a class.) All protocols are thus “existential types” whether or not the language supports values having that type.
>> It is incorrect to say that protocols with associated types (or requirements involving Self) are “non-existential”.
> I haven't heard people using this term myself, but I imagine they probably mean "can't form an existential value with the protocol". There certainly appears to be a lot of confusion in the community with many not realizing that this is a temporary limitation of the implementation, not a necessary fact.
This sort of confusion is why we try to keep the word “existential” out of diagnostics. (We could have also had success going the other way, and consistently referring to protocols as existential even in non-existential-value cases, but originally we decided it was better to stick with Objective-C’s terms even if it was a bit limiting and awkward.)
More information about the swift-evolution