<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">2016-08-11 0:40 GMT+03:00 Slava Pestov <span dir="ltr">&lt;<a href="mailto:spestov@apple.com" target="_blank">spestov@apple.com</a>&gt;</span>:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>I think pointing a Mirror at a metatype value could be a good a mechanism for getting information about the type&#39;s stored properties and other members.</div><div><br></div><div>FWIW Mirrors are inspired by a feature of the same name in the Self language, which made reflection somewhat more principled than the disorganized APIs you see in Java and C#. Perhaps the latter are not a good model to follow here :-)</div></div></blockquote><div><br></div><div>Swift and Self lie in different families of languages.</div><div>In Self (and Smalltalk, and ObjC), types don&#39;t really matter: one can modify methods, which some object has, independently of all other objects.</div><div>Because of this dynamism, reflection of types has little value in these languages.</div><div><br></div><div>On the other hand, in Swift (and C++, and Java) types do matter. It is useful to get, for example, a Method, and be sure that you can call it on all instances of matching type.</div><div>I think that Swift should favor types and not instances, as it unfortunately does today.</div><div><br></div><div>This is how I imagine reflection API. We have a type ID and can request different information about it. For example:  func getMethod(name: String) -&gt; Method?</div><div>Most importantly, we should be able to get IDs of other related types, and related type IDs of theirs, and so on, without collecting excessive data.</div></div></div></div>