<div dir="ltr">Thank you! If you have other ideas I&#39;d love to hear them, even if they&#39;re completely different. I think this is a topic that deserves to &#39;simmer&#39; for a while.<div><br></div><div>You bring up an important point: should reflection be opt-in or opt-out? I&#39;ve seen arguments for both options, and I think it&#39;s definitely a point that needs to be very carefully discussed. Importantly, opt-out makes this a sort-of-zero cost abstraction; only types that need the functionality take the performance and metadata size hit. This is something that the core team seems to find important.</div><div><br></div><div>If it is opt-in, though, there are certainly a bunch of framework base types that should be opted-in, so that all their subclasses can be reflected upon, providing most of the practical benefits of default opt-in. Giving UIView and NSView this functionality would be a starting point, and *maybe* NSObject (although that would have effects upon all of Swift Foundation).</div><div><br></div><div>Best,</div><div>Austin</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, May 26, 2016 at 7:42 PM, Callionica (Swift) <span dir="ltr">&lt;<a href="mailto:swift-callionica@callionica.com" target="_blank">swift-callionica@callionica.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">This is important and really useful. There&#39;s a lot to like here. I have been thinking about property reflection recently too. Don&#39;t have time to write too much on it now, but was wondering what was the thinking behind suggesting an opt-in? For me, I would hope that getting access to a single property object that holds the getter and setter functions would be almost as simple as the way we obtain a function reference for a method (by naming the item in code) and would hope that it would work for all types. <span class="HOEnZb"><font color="#888888"><div><br></div><div>-- Callionica</div></font></span><div class="HOEnZb"><div class="h5"><div><br>On Thursday, May 26, 2016, Austin Zheng via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt; wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi swift-evolution,<div><br></div><div>For those who are interested I&#39;d like to present a pre-pre-proposal for reflection upon a type&#39;s properties and solicit feedback. </div><div><br></div><div>First of all, some caveats: this is only a very small piece of what reflection in Swift might look like one day, and it&#39;s certainly not the only possible design for such a feature. Reflection comes in many different forms, and &quot;no reflection&quot; is also an option. Deciding what sort of reflection capabilities Swift should support is a prerequisite to stabilizing the runtime API, which I imagine has resilience consequences. I&#39;m not really interested in <i>defending</i> this specific proposal per se, as I am looking for a jumping-off point to explore designs in this space.</div><div><br></div><div>Anyways, here is a gist outlining the public API to the feature: </div><div><br></div><div><a href="https://gist.github.com/austinzheng/699d47f50899b88645f56964c0b7109a" target="_blank">https://gist.github.com/austinzheng/699d47f50899b88645f56964c0b7109a</a><br></div><div><br></div><div>A couple of notes regarding the proposal:</div><div><br></div><div>The API names need improvement. Suggestions welcome.</div><div><br></div><div>It&#39;s opt-in: types have to conform to a special protocol for the compiler to generate whatever hooks, metadata, and support code is necessary. Once a type conforms, the interface to the reflection features naturally present themselves as protocol methods. It would be great to allow an extension to retroactively enable reflection on a type vended by another module, although I have no idea how feasible that is.</div><div><br></div><div>It uses &quot;views&quot;: there are four types of views, two of each in the following categories: typed vs untyped, get-only versus get-set. A view is a struct representing a property on an instance of a type (or maybe a metatype, for type properties). It allows you to get information about that property (like its name) and try getting and setting its values.</div><div><br></div><div>(You can get a get-only view to a property, and then try and upgrade it later to a get-set view, if the underlying property is get-set. If you don&#39;t care about setting, though, you can just work exclusively with get-only views.)</div><div><br></div><div>It supports both typed and untyped access. You can ask for a property view specifically for (e.g.) a `String` property, and if you get one you can be assured that your getting and setting operations will be type safe. You can also ask for an &quot;untyped&quot; property view that exposes the value as an Any, and allows you to try (and possibly fail, with a thrown error) to set the value.</div><div><br></div><div>The requirements part of it is composable. For example, you can imagine a future &quot;FullyReflectable&quot; protocol that simply inherits from &quot;PropertyReflectable&quot;, &quot;MethodReflectable&quot;, and other reflectable protocols. Or maybe a library requires reflection access to types that it needs to work with, and it can create its own protocols that inherit from &quot;PropertyReflectable&quot; and naturally enforce reflection support on the necessary types.</div><div><br></div><div>It looks a bit cumbersome, but there&#39;s room for refinement. Users won&#39;t necessarily see all the types, though, and the interface is pretty straightforward:</div><div><br></div><div>```</div><div>myPerson.typedReadWriteProperty&lt;Int&gt;(&quot;age&quot;)?.set(30)</div><div><br></div><div>try myPerson.allNamedProperties[&quot;age&quot;]?.set(30)</div><div>```</div><div><br></div><div>I&#39;m not yet sure how it should interact with access control (my inclination is that it would only expose the properties you&#39;d be able to directly access), or property behaviors (I think get-set behavior is fundamental to properties, although &quot;behavior metadata&quot; on the views might be useful).</div><div><br></div><div>I&#39;d also have to figure out how it would operate with generic types or existentials.</div><div><br></div><div>Anyways, thanks for reading all the way to the end, and any feedback, criticism, or alternative proposals would be greatly appreciated.</div><div><br></div><div>Best,</div><div>Austin</div></div>
</blockquote></div>
</div></div></blockquote></div><br></div>