I think the names should be bikeshedded more still. From your examples they seem to make sense when I mentally add Of like TypeOf<> and SubTypeOf<>, but since you are not commenting on why that is wrong or right or misleading, or at least I have missed your reply on that, I am still a bit at loss. Maybe we need other words altogether?
Sent from my iPhone On 2 Oct 2016, at 05:04, Brent Royal-Gordon via swift-evolution <[email protected]> wrote: >> On Sep 30, 2016, at 10:25 PM, Russ Bishop <[email protected]> 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 > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
