[swift-evolution] [Pitch] Refactor Metatypes

[Anton Zhilin]

2016-09-29 3:31 GMT+03:00 Colin Barrett via swift-evolution <
swift-evolution at swift.org>:


>    -
>
>    Type<T> is the concrete type of T.self. A Type<T> only ever has one
>    instance, T.self; even if T has a subtype U, Type<U> is not a subtype
>    of Type<T>.
>    -
>
>    Subtype<T> is the supertype of all Types whose instances are subtypes
>    of T, including T itself:
>    -
>
>    If T is a struct or enum, then Type<T> is the only subtype of
>    Subtype<T>.
>    -
>
>    If T is a class, then Type<T> and the Types of all subclasses of T are
>    subtypes of Subtype<T>.
>    -
>
>    If T is a protocol, then the Types of all concrete types conforming to
>    T are subtypes of Subtype<T>. Type<T> is not itself a subtype of
>    Subtype<T>, or of any Subtype other than Subtype<Any>.
>
> I’m having trouble reconciling this with rule #2 above, which states that
> “Subtype is the supertype of all Types whose instances are subtypes of T,
> including T itself.” Which one is wrong, or am I confused?
>
#2 applies to types, and #5 applies to protocols. If T is a type, then
Type<T> is always a subtype of Subtype<T>. If T is a protocol, then Type<T>
is never a subtype of Subtype<T>.

One thing I haven’t understood the motivation for exactly is what someone
> would be able to do with a Proto.self. Dynamic conformance checking? For a
> concrete T, having its .self seems useful for doing dynamic casts and such,
> but I don’t understand why for a Proto you need to have both. You did a
> good job of explaining why T.Protocol and T.Type are different, but not why
> both of them need to exist. So you could definitely do more to spell out
> the use-cases here.
>
I honestly can’t imagine a use case for .Protocol currently. Maybe
enumerating protocols that exist in the program, just for the sake of it.


>    -
>
>    Metatypes of functions are a little bit more special (the subtyping
>    relation on functions flips around for parameter types
>    <https://en.wikipedia.org/wiki/Covariance_and_contravariance_(computer_science)>
>    ):
>    -
>       - Type<(Any) -> Void> is a subtype of Subtype<(Int) -> Void> etc.
>       - Type<(Void) -> Int> is a subtype of Subtype<(Void) -> Any>
>
>
> Does this potentially expose contravariant type parameters, and is that an
> issue? (I’m trying to imagine a scenario where you could have an A on the
> left hand side of an arrow and have that leak out to other clients, but I
> haven’t had a chance to write much Swift 3 yet, unfortunately.)
>
Could you give a code example, where that would be an issue?
​
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160929/62d6d9ca/attachment.html>