<html><body><div>This is unfortunate, because then the meaning of "existential" and "non-existential" in Swift are just the opposite of their respective meaning in standard terminology :-(<br></div><div><br data-mce-bogus="1"></div><div>-Thorsten<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div><br>Am 25. Mai 2016 um 14:27 schrieb Brent Royal-Gordon <brent@architechies.com>:<br><br><div><blockquote type="cite"><div class="msg-quote"><div class="_stretch"><span class="body-text-content"><blockquote type="cite" class="quoted-plain-text">AFAIK an existential type is a type T with type parameters that are still abstract (see for example <a href="https://en.wikipedia.org/wiki/Type_system#Existential_types" data-mce-href="https://en.wikipedia.org/wiki/Type_system#Existential_types">https://en.wikipedia.org/wiki/Type_system#Existential_types</a>), i.e. have not been assigned concrete values.</blockquote><br>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".<br><br>If I am misusing the terminology in this area, please understand that that's what I mean when I use that word.<br><br>-- <br>Brent Royal-Gordon<br>Architechies<br><br></span></div></div></blockquote></div></div></body></html>