<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">2016-07-15 3:52 GMT+03:00 Brent Royal-Gordon <span dir="ltr">&lt;<a href="mailto:brent@architechies.com" target="_blank">brent@architechies.com</a>&gt;</span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><span class="">&gt; On Jul 14, 2016, at 5:24 PM, Anton Zhilin via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>&gt; wrote:<br>
&gt;<br>
&gt; Ok, I forgot about it. Type&lt;T&gt; should have all features of T.Type, except that Type&lt;T&gt; will not contain static methods of T.<br>
<br>
</span>Why? It seems to me like the most natural way to design this by far is to have `Type&lt;T&gt;` be the type returned by `type(of:)`, which means it would have all static and class members on it.</blockquote><div><br></div><div>An example where such behavior is required:</div><div><br></div><div><div><font face="monospace, monospace">protocol HasStatic { static func staticMethod() }</font></div><div><font face="monospace, monospace">func callStatic(_ type: HasStatic.Type) {</font></div><div><font face="monospace, monospace">    type.staticMethod()</font></div><div><font face="monospace, monospace">}</font></div></div><div><br></div><div>I finally understand the reasons for keeping metatypes <font face="monospace, monospace">T.Type</font>, &quot;sealed&quot; inside <font face="monospace, monospace">Type&lt;T&gt;</font>. And such a feature would look odd on a struct.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">It also seems like `Type&lt;T&gt;`&#39;s type would absolutely have to be `Type&lt;Type&lt;T&gt;&gt;`, and some form of infinite regress is absolutely necessary (though in practice it could probably be simulated by having the first metatype with no static members act as its own type, or with some other form of lazy instantiation).</blockquote><div><br></div><div>I don&#39;t see any problems with Type&lt;Type&lt;T&gt;&gt;. There is finite number of types that are used in the program, and compiler can collect and store information about them all statically. Am I right?</div><div><br></div></div></div></div>