[swift-evolution] [Pitch] Refactor Metatypes

Xiaodi Wu xiaodi.wu at gmail.com
Thu Sep 29 23:21:45 CDT 2016

Great explanation.

Can you elaborate on your two reasons for the proposed Type<T>?

In particular, what do you mean by inheritable and non-inheritable members
of T? Where do these come into play? How is the current T.Type deficient in
this respect?

Regarding (2), it is already possible to do precise type matches using `==`
instead of `is` (see corelibs-foundation for extensive uses). What does the
proposal offer that goes beyond what we currently have?

On Thu, Sep 29, 2016 at 22:57 Brent Royal-Gordon <brent at architechies.com>

> > On Sep 29, 2016, at 8:14 PM, Xiaodi Wu via swift-evolution <
> swift-evolution at swift.org> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160930/edbf4d88/attachment.html>

More information about the swift-evolution mailing list