<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Mar 2, 2016, at 5:50 PM, Joe Groff via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div class="">Something else to consider: Maybe we should require Any<...> to refer to all existential types, including single-protocol existentials (so you'd have to say var x: Any<Drawable> instead of var x: Drawable). Between static method requirements, init requirements, and contravariant self and associated type constraints, there are a lot of ways our protocols can diverge in their capabilities as constraints and dynamic types. And with resilience, *no* public protocol type can be assumed to resilient implicitly conform to its protocol, since new versions may introduce new requirements that break the self-conformance. If protocols are namespaced separately from types, you could still do something like:</div><div class=""><br class=""></div></div><blockquote class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; margin: 0px 0px 0px 40px; border: none; padding: 0px;"><div class=""><div class="">typealias Drawable: Drawable = Any<Drawable></div><div class=""><br class=""></div></div></blockquote><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">if you intend to use the protocol type primarily as a dynamic type (and assert that it's self-conforming).</span><br class=""></div></blockquote><br class=""></div><div>Any<> syntax also allows for a few useful extensions and syntax refinements:</div><div><br class=""></div><div>- We could gain back the often-missed ability from ObjC to express a type that both inherits a base class and implements a protocol, spelling that Any<BaseClass, Protocol>. That's less weird than using protocol<...> to refer to class constraints.</div><div>- We can make our syntax for existential metatypes (some dynamic type that conforms to P, "exists T: P. (T.Type)") and metatypes-of-existentials (the exact type of the existential, "(exists T: P. T).Type". Currently we spell the former as `P.Type` and the latter as `P.Protocol`, and people writing generics occasionally get caught out when substituting `T = P` into `T.Type` gives them `P.Protocol`. It would make sense to me to put `.Type` inside the Any<> brackets for existential metatypes, Any<P.Type> (today's P.Type), and have Any<P>.Type refer to the exact type `Any<P>` (today's P.Protocol).</div><div><br class=""></div><div>-Joe</div></body></html>