[swift-evolution] [Completing Generics] Any<> syntax, base class constraints, and existential metatypes
Joe Groff
jgroff at apple.com
Fri Mar 4 13:16:48 CST 2016
> On Mar 2, 2016, at 5:50 PM, Joe Groff via swift-evolution <swift-evolution at swift.org> wrote:
>
> 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:
>
> typealias Drawable: Drawable = Any<Drawable>
>
> if you intend to use the protocol type primarily as a dynamic type (and assert that it's self-conforming).
Any<> syntax also allows for a few useful extensions and syntax refinements:
- 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.
- 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).
-Joe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160304/12dc3512/attachment.html>
More information about the swift-evolution
mailing list