<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"><<a href="mailto:brent@architechies.com" target="_blank">brent@architechies.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> On Jul 14, 2016, at 6:33 PM, Anton Zhilin <<a href="mailto:antonyzhilin@gmail.com">antonyzhilin@gmail.com</a>> wrote:<br>
><br>
> 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 "thing" everywhere it's referred to. Types don'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't express those.<br></blockquote><div><br></div><div>Current plan is that <font face="monospace, monospace">Type<T></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<T></font> and make it a class?</div><div>Classes can'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<T></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<>` syntax, especially if it's something that could at least partially be written in the standard library (how nice would it be if we had `final class Type<Describing>` in the generated headers?), and I really like the idea of extending a metatype to conform to a protocol. But a lot of what's being discussed here, I just don't get. What'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<T></font> cannot, namely dynamic dispatch of static/class methods.</div><div>If that usage is important enough, then I'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="">> I don't see any problems with Type<Type<T>>. 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<T>(type: T.Type, depth: Int) {<br>
print(type)<br>
guard depth > 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<T> = (T, Int)</font></div><div><font face="monospace, monospace">func wrap<T>(_ value: T) -> SomeGeneric<T></font></div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace">func recursivelyPrint<T>(_ value: T, depth: Int) {</font></div><div><font face="monospace, monospace"> print(type)</font></div><div><font face="monospace, monospace"> guard depth > 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't create any types dynamically, not only for <font face="monospace, monospace">SomeGeneric<T> = T.Type</font>.</div><div>So this problem is not specific to Type<T>, and should not be solved separately.</div></div></div></div>