<div dir="ltr">On Fri, Sep 30, 2016 at 5:56 PM, Brent Royal-Gordon <span dir="ltr"><<a href="mailto:brent@architechies.com" target="_blank">brent@architechies.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> On Sep 29, 2016, at 9:21 PM, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com">xiaodi.wu@gmail.com</a>> wrote:<br>
><br>
> Can you elaborate on your two reasons for the proposed Type<T>?<br>
><br>
> 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?<br>
<br>
</span>Consider a snippet of code like this:<br>
<br>
class A { init(a: Int) { } }<br>
class B: A { init(b: Int) { super.init(a: b) } }<br>
<br>
You can call `A.init(a:)` directly:<br>
<br>
A(a: 0)<br>
A.self.init(a: 0)<br>
<br>
However, if you try to assign `A`'s type instance to a variable and do it through there, you can't:<br>
<br>
let aType: A.Type = A.self<br>
aType.init(a: 0) // Error: constructing an object of class type 'A' with a metatype value must use a 'required' initializer<br>
<br>
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:)`.<br>
<br>
`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.<br>
<br>
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.<br>
<br>
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.<br>
<span class=""><br>
> 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?<br>
<br>
</span>`as?` compatibility, I suppose? Honestly, that's just something I noticed when I was writing it up. It might not be important.<span class="HOEnZb"><font color="#888888"><br></font></span></blockquote><div><br></div><div>This is a very clear answer. So for my understanding, what you're saying is: without other language features not yet proposed, `Type<T>` does not in itself enable a particularly notable use case that's not currently possible today. It is being included in this proposal because the original design of Swift lumped two things together for simplicity, but you disagree with that design decision and want the distinction to be utterable. Is that more or less the gist of it?</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="HOEnZb"><font color="#888888">
--<br>
Brent Royal-Gordon<br>
Architechies<br></font></span></blockquote><div><br></div><div> </div></div><br></div></div>