<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div>Now that SE-0156 has been accepted, I’ve been thinking recently that it might be nice to extend this proposal with some kind of generalised “concrete-type existential”. As I see it, there are two parts to an existential like the one proposed here:<br class=""><font color="#5856d6" class=""><br class=""></font><concrete type> & <protocol conformances...><br class=""><font color="#5856d6" class=""><br class=""></font>For classes, the “concrete type” part of this relationship is flexible: the instance may be the exact class X, or some subclass of X, and in that case it may or may not conform to additional protocols. So that’s why this existential has value; because, say, “NSObject & Collection” may be satisfied for some subclasses of NSObject.<br class=""><font color="#5856d6" class=""><br class=""></font>Value-types cannot have subtypes, so that part of the constraint is fixed. Likewise, until now, the set of protocol conformances for a concrete type was fixed. That is to say that “Array <T> & Equatable” would be a nonsense constraint, because Array<T> does not conform to Equatable and will never conform to Equatable. <br class=""><font color="#5856d6" class=""><br class=""></font>But we have approached everything focussed on the idea that only flexibility in satisfying the concrete-type constraint matters. Now that we have conditional conformances, however, the protocol-conformance side of the equation also becomes interesting, even for value-types. The existential “Array<T> & Equatable” is no longer a nonsense constraint - it is a valid constraint which implies some underlying constraints on T. In this case the underlying constraints might be simple (T: Equatable), but in general for any protocol “SomeProtocol”, the conditional conformance requirements might be long and complex, or even completely unknown to us (e.g. if the Foo: SomeProtocol conformance is added retroactively by another module).<br class=""><br class=""></div><div>For example, I should be able to write:</div><div><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div><font face="Courier" class="">func checkArray<T>(_ a: Array<T> & SomeProtocol) -> Bool {</font></div><div><font face="Courier" class=""> // …</font></div><div><font face="Courier" class="">}</font></div></blockquote><div><br class=""></div><div>Without needing to be copy-paste the requirements which make Array conform to SomeProtocol, or even needing to know the specifics of those constraints at all.</div><div><br class=""></div><div><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">The solution would be to extend SE-0156 to allow { <non-class concrete type> & <protocol conformances> } existentials.</div><div class=""><br class=""></div><div class="">- Karl</div></div></div><br class=""></body></html>