2016-09-29 3:31 GMT+03:00 Colin Barrett via swift-evolution < [email protected]>:
> - > > 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?
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
