<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">2016-07-15 9:25 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">&gt; On Jul 14, 2016, at 6:33 PM, Anton Zhilin &lt;<a href="mailto:antonyzhilin@gmail.com">antonyzhilin@gmail.com</a>&gt; wrote:<br>
&gt;<br>
&gt; And such a feature would look odd on a struct.<br>
<br>
</span>But why would it be a struct? Types are obvious candidates to have identities; the type is the same &quot;thing&quot; everywhere it&#39;s referred to. Types don&#39;t have value semantics; if you perform a mutating operation on a type, that mutation is visible everywhere. Types (at least class types) have subtype relationships; structs can&#39;t express those.<br></blockquote><div><br></div><div>Current plan is that <font face="monospace, monospace">Type&lt;T&gt;</font> will contain <font face="monospace, monospace">T.Type</font> that will do all the work for us. Maybe it will be better to pour internals of <font face="monospace, monospace">T.Type</font> directly into <font face="monospace, monospace">Type&lt;T&gt;</font> and make it a class?</div><div>Classes can&#39;t help here in terms of inheritance, because types will also reflect subtyping relationships for protocols. Current plan is to use methods instead of casts and subtyping behaviour of <font face="monospace, monospace">Type&lt;T&gt;</font>.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I like the `Type&lt;&gt;` syntax, especially if it&#39;s something that could at least partially be written in the standard library (how nice would it be if we had `final class Type&lt;Describing&gt;` in the generated headers?), and I really like the idea of extending a metatype to conform to a protocol. But a lot of what&#39;s being discussed here, I just don&#39;t get. What&#39;s the benefit of switching to structs? Of removing type members?<br></blockquote><div><br></div><div>I finally could understand what metatypes can do and <font face="monospace, monospace">Type&lt;T&gt;</font> cannot, namely dynamic dispatch of static/class methods.</div><div>If that usage is important enough, then I&#39;m for leaving (sealed) <font face="monospace, monospace">T.Type</font> because of that feature.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">&gt; 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?<br>
<br>
</span>Maybe not:<br>
<br><font face="monospace, monospace">
        func recursivelyPrint&lt;T&gt;(type: T.Type, depth: Int) {<br>
                print(type)<br>
                guard depth &gt; 0 else { return }<br>
                recursivelyPrint(type: type.dynamicType, depth: depth - 1)<br>
        }<br>
        recursivelyPrint(type: Int.self, depth: 5)</font></blockquote><div><br></div><div>Great example. But we can adapt it to tuples or any generic type:</div><div><br></div><div><font face="monospace, monospace">typealias SomeGeneric&lt;T&gt; = (T, Int)</font></div><div><font face="monospace, monospace">func wrap&lt;T&gt;(_ value: T) -&gt; SomeGeneric&lt;T&gt;</font></div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace">func recursivelyPrint&lt;T&gt;(_ value: T, depth: Int) {</font></div><div><font face="monospace, monospace">    print(type)</font></div><div><font face="monospace, monospace">    guard depth &gt; 0 else { return }</font></div><div><font face="monospace, monospace">    recursivelyPrint(wrap(value), depth: delth - 1)</font></div><div><font face="monospace, monospace">}</font></div><div><br></div><div>Currently, such code does not compile, because compiler can&#39;t create any types dynamically, not only for <font face="monospace, monospace">SomeGeneric&lt;T&gt; = T.Type</font>.</div><div>So this problem is not specific to Type&lt;T&gt;, and should not be solved separately.</div></div></div></div>