[swift-evolution] [Pitch] Refactor Metatypes

[Xiaodi Wu]

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 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?
On Thu, Sep 29, 2016 at 9:44 PM Nevin Brackett-Rozinsky via swift-evolution
<swift-evolution at swift.org> wrote:

> From Brent’s explanation, it sounds to me like “Type” and “StaticType”
> respectively would be more descriptive than “Subtype” and “Type” as
> proposed.
>
> Nevin
>
>
> On Thu, Sep 29, 2016 at 10:29 PM, Brent Royal-Gordon via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>> > On Sep 29, 2016, at 3:24 PM, Russ Bishop via swift-evolution <
>> swift-evolution at swift.org> wrote:
>> >
>> > Why would we not have type(of:) and subtype(of:)? Why would I want the
>> Subtype<T> instead of the specific Type<T>?
>>
>> Let's turn this around. Suppose you write:
>>
>>         let obj: NSObject = …
>>         let ty = type(of: obj)
>>
>> What is `ty`? Well, it's a `Type<NSObject>`, and there's only one of
>> those: `NSObject.self`. So there's only one possible instance that could be
>> assigned to that variable.
>>
>> This is true in general: If `type(of:)` returns `Type<T>`, then it can
>> only have one possible return value. In other words, the return value of
>> `type(of:)` would always be the *static* type of the variable, not its
>> dynamic type. There may be some narrow cases where that'd be useful, but
>> 99% of the time, you want `subtype(of:)` because you're trying to discover
>> which of many dynamic subtypes of the static type you're actually dealing
>> with. So most uses of `type(of:)` would probably be mistaken attempts to
>> perform `subtype(of:)` instead.
>>
>> > What is the rationale for losing the meta type relationships by having
>> Type<U> not be a subtype of Type<T>?
>>
>> The relationships aren't lost; they're just expressed through `Subtype`,
>> not `Type`.
>>
>> Again, turn this around. `Subtype` is the normal thing that you'll want
>> to use most of the time. `Type` is the weird thing whose existence is hard
>> to explain. (One version of this proposal used `Type` for `Subtype` and
>> `ExactType` for `Type` in order to imply that subtype is usually what you
>> want, but some of the contributors weren't happy with that.)
>>
>> So, `Type` is the weird thing. Why does it exist? Two reasons:
>>
>> 1. `Subtype<T>` only includes *inheritable* type members of `T`.
>> `Type<T>` also includes *non-inheritable* members, particularly
>> non-required initializers.
>>
>> 2. It allows precise type matches: `subty is Subtype<NSObject>` would
>> match for any subtype of `NSObject`, whereas `subty is Type<NSObject>`
>> would only match for `NSObject` itself.
>>
>> --
>> Brent Royal-Gordon
>> Architechies
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160930/58fe918d/attachment.html>