> On Sep 30, 2016, at 10:25 PM, Russ Bishop <xen...@gmail.com> wrote: > This topic is confusing enough that I think it warrants being extremely clear > about the naming. Type and Subtype feel like a class hierarchy and that’s not > exactly what we are doing here. If Type<T> represents the static type of T > then let’s just call it StaticType<T>. If the thing most people want to work > with is the dynamic type Subtype<T> then let’s just call it that: > DynamicType<T>. > > Now this becomes really clear: > > class A { } > class B: A { } > > //clearly only ever represents A as a type > let metatype_1 = statictype(of: A()) > > //clearly might dynamically be A, B, or any subclass > let metatype_2 = dynamictype(of: A()) > > > It also becomes trivially easy to explain because the name follows the > explanation. Why can I only use required initializers on DynamicType<A>? > Because we don’t know if the initializer is available; the dynamic type may > differ at runtime. StaticType<A> knows exactly what is available on A because > it is statically known at compile time.
But that *isn't* clear about the relationship between DynamicType and StaticType—specifically, that there are no concrete DynamicTypes, and all DynamicType variables will contain StaticType instances. In some drafts, I suggested pairs like `Type` and `SpecificType`: func type<T>(of: T) -> Type<T> func size<T>(of: SpecificType<T>) -> Int (Incidentally, a third benefit of the redesign is that parameters can now be clear about whether they're actually sensitive to the specific dynamic type you pass or they're just being used to pin a generic parameter to a static type. For instance, when you call `UnsafeMutableRawPointer.initializeMemory(as:at:count:to:)`, it doesn't care what dynamic type you pass, but when you call `URLProtocol.registerClass(_:)`, it does. This would be represented—using the proposal's names—by `initializeMemory` taking a `Type<T>` and `URLProtocol` taking a `Subtype<URLProtocol>` or `Subtype<AnyObject>`.) -- Brent Royal-Gordon Architechies _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution