> On Sep 29, 2016, at 8:14 PM, Xiaodi Wu via swift-evolution
> <[email protected]> wrote:
>
> I'm confused by this explanation.Today, `type(of:)` is the new
> `.dynamicType`. Is this proposal suggesting a silent change so that it now
> returns the static type? If so, why (particularly when you explain that this
> is often *not* what you would want)?
I'm short-handing the names to talk about the return values. In other words, I
assume that, if we have both `type(of:)` and `subtype(of:)`, their signatures
would be:
func type<T>(of: T) -> Type<T>
func subtype<T>(of: T) -> Subtype<T>
And I'm saying that, given these names, `type(of:)` is confusing and
near-useless, whereas `subtype(of:)` is what you almost always want.
We *could*, of course, have a function called `type(of:)` which returned
`Subtype<T>` and had the semantics I'm referring to as `subtype(of:)`. A name
is just a name.
> I'm also somewhat puzzled about the proposed design. This proposal explains
> that Subtype<T> should be a supertype of Type<T> and its subtypes. Why is a
> supertype named Subtype?
Because a type's name should describe the *instances*; that's why you don't put
"Class" at the end of all of your class names. (It's also why we're proposing
`Type<T>` instead of `Metatype<T>`.)
Every instance of `Subtype<T>` is the type instance for a subtype of `T`. For
instance, in this hierarchy:
NSObject
NSResponder: NSObject
NSView: NSResponder
`Type<NSResponder>` is a `Subtype<NSObject>`, but not a `Subtype<NSView>`.
Thus, this reads correctly:
let aType: Subtype<NSResponder> = NSView.self
Whereas this does not:
let aType: Supertype<NSResponder> = NSView.self
--
Brent Royal-Gordon
Architechies
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
