> 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
