<html><body><div>I'd like to reiterate that an existential is a protocol with self type requirements and/or associated types that have not been assigned. Protocols without self type requirements or associated types are *not* existentials!<br></div><div><br data-mce-bogus="1"></div><div>(Neither would be protocols where all associated types have been assigned (this makes only sense for associated types inherited from another protocol and is currently not possibly in Swift if I am not mistaken)).<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div>We should not confuse this.<br data-mce-bogus="1"></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 12:23 schrieb Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org>:<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">However, I believe this would have a significant advantage: it would clarify the distinction between an existential and a constraint. It would more clearly mark where you are taking on the abstraction overhead of an existential. It would also improve the non-existential type situation: in the short term, it would make it clearer where uses of associated type protocols like `Comparable` would not be permitted; in the long term, once we have type-erased existentials for those protocols, it would make it clearer when type erasure was in effect.</blockquote><br>Sorry to self-reply, but I had some additional thoughts on this.<br><br>Swift's type system has a logical hierarchy of types. A type's supertypes include any protocols it conforms to, and then the protocols they conform to, ultimately rooted at Any. Additionally, a class's supertypes include its superclass, and then its superclass, and so on up to a root class, and then AnyObject, and finally Any once more. And of course, Any<…> lets you build composite types out of several protocols which fit into this framework: Any<Foo, Bar> is a subtype of both Foo and Bar and a supertype of any type which conforms to both Foo and Bar.<br><br>At an implementation level, however, this is only partially true. A class can be transformed into its superclass, all the way up to AnyObject, without any change in memory representation. But once you enter the world of protocols, everything changes. To cast to a protocol, you must place the instance in an existential, a different instance with a different memory layout. This can have significant performance consequences; for example, it's the reason you can't use `as` to convert an array of instances to an array of some protocol they all belong to.<br><br>Requiring the use of `Any<…>` to mark any existential would help reinforce this distinction. It would give users a better understanding of what their code was actually doing and why they might not be able to do things like make certain seemingly sensible casts.<br><br>(Although technically, this would seem to imply that AnyObject's future equivalent should *not* require an Any<>. Hmm.)<br><br>-- <br>Brent Royal-Gordon<br>Architechies<br><br>_______________________________________________<br>swift-evolution mailing list<br><a href="mailto:swift-evolution@swift.org" data-mce-href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" data-mce-href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br></span></div></div></blockquote></div></div></body></html>