> On Sep 29, 2016, at 9:21 PM, Xiaodi Wu <xiaodi...@gmail.com> wrote: > > 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?
Consider a snippet of code like this: class A { init(a: Int) { } } class B: A { init(b: Int) { super.init(a: b) } } You can call `A.init(a:)` directly: A(a: 0) A.self.init(a: 0) However, if you try to assign `A`'s type instance to a variable and do it through there, you can't: let aType: A.Type = A.self aType.init(a: 0) // Error: constructing an object of class type 'A' with a metatype value must use a 'required' initializer This is a reflection of the fact that an `A.Type` could be `A.self` or `B.self` (or any other subclass of `A`), and `B.self` may not have an `init(a:)`. `Type<A>` does not have this problem because it *is* guaranteed to be an `A`. It can express initializers and potentially anything else we might add that doesn't get inherited. Of course, that isn't hugely useful right now because `Type<T>` only has one instance, and you can just refer to that instance directly. But I don't like that this distinction is unutterable; `Type<T>` corrects that. And I think we may have features in the future where this is useful. For instance, if reflection ever gains the ability to access non-stored-property members, the distinction between `Subtype<T>` and `Type<T>` may become important. And if we ever get the ability to conform metatypes to protocols, I think non-inheritable conformances may be a good thing. > 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? `as?` compatibility, I suppose? Honestly, that's just something I noticed when I was writing it up. It might not be important. -- Brent Royal-Gordon Architechies _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution