<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 27 May 2016, at 10:43 PM, Matthew Johnson <<a href="mailto:matthew@anandabits.com" class="">matthew@anandabits.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><blockquote type="cite" class="" style="font-family: Helvetica; font-size: 15px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div class=""><br class="Apple-interchange-newline">On May 27, 2016, at 9:22 AM, Anders Ha <<a href="mailto:hello@andersio.co" class="">hello@andersio.co</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><blockquote type="cite" class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-ligatures: normal; font-variant-position: normal; font-variant-caps: normal; font-variant-numeric: normal; font-variant-alternates: normal; font-variant-east-asian: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div class=""><br class="Apple-interchange-newline">On 27 May 2016, at 9:30 PM, Matthew Johnson <<a href="mailto:matthew@anandabits.com" class="">matthew@anandabits.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="auto" class=""><div class=""><br class=""><br class="">Sent from my iPad</div><div class=""><br class="">On May 27, 2016, at 5:45 AM, Anders Ha via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class="">I wonder how the views would work with the value semantic of structs.</div></blockquote><div class=""><br class=""></div>Not all value types have value semantics. It's important to not forget that. I would like to see a way to make that distinction clear in our code but that is a conversation for another thread.</div></div></blockquote><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-ligatures: normal; font-variant-position: normal; font-variant-caps: normal; font-variant-numeric: normal; font-variant-alternates: normal; font-variant-east-asian: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br class=""></div><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-ligatures: normal; font-variant-position: normal; font-variant-caps: normal; font-variant-numeric: normal; font-variant-alternates: normal; font-variant-east-asian: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">I meant value types. Thanks for pointing out that. :-)</div><br class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-ligatures: normal; font-variant-position: normal; font-variant-caps: normal; font-variant-numeric: normal; font-variant-alternates: normal; font-variant-east-asian: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><blockquote type="cite" class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-ligatures: normal; font-variant-position: normal; font-variant-caps: normal; font-variant-numeric: normal; font-variant-alternates: normal; font-variant-east-asian: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div class=""><div dir="auto" class=""><div class=""><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class=""></div><div class="">The view types proposed, if not being a compiler magic, would need to have a reference to the reflected instance. They are also escapable unless special rules for the view types are enforced. So… perhaps we would want less magic and special rules?</div><div class=""><br class=""></div><div class="">IMO these views are not necessary, and can be consolidated into typed/untyped get/set calls on `Reflectable`. However, if the intention is to amortize the type metadata lookup, or not to introduce any kind of lookup caching in the runtime, perhaps we can introduce instead<span class="Apple-converted-space"> </span><i class="">property descriptors</i>.</div><div class=""><br class=""></div><div class="">(A quick dump of my idea:</div></div></blockquote><blockquote type="cite" class=""><div class=""><div class=""><a href="https://gist.github.com/andersio/9ff02257b5c89b35fd523dcd09e484e4" class="">https://gist.github.com/andersio/9ff02257b5c89b35fd523dcd09e484e4</a>)</div></div></blockquote><div class=""><br class=""></div><div class="">Property descriptors could be useful in the sense that they wouldn't need to refer back to the instance. But I would also like to see a way to get something like a lens into the property for a specific instance which is what the views allow for. This design doesn't allow for that. Maybe we want to allow you to query for property descriptors alone, lenses alone, or the combination in a view.</div><div class=""><br class=""></div></div></div></div></blockquote><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-ligatures: normal; font-variant-position: normal; font-variant-caps: normal; font-variant-numeric: normal; font-variant-alternates: normal; font-variant-east-asian: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br class=""></div><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-ligatures: normal; font-variant-position: normal; font-variant-caps: normal; font-variant-numeric: normal; font-variant-alternates: normal; font-variant-east-asian: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">Just for the record, I was meaning that the user can request a <i class="">typed descriptor</i> of a particular named instance properties (and even class properties) at runtime from the metatype. Users may then use these typed descriptors to query or modify the value from a specific instance.</div><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-ligatures: normal; font-variant-position: normal; font-variant-caps: normal; font-variant-numeric: normal; font-variant-alternates: normal; font-variant-east-asian: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br class=""></div><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-ligatures: normal; font-variant-position: normal; font-variant-caps: normal; font-variant-numeric: normal; font-variant-alternates: normal; font-variant-east-asian: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">It is like KVC, but uses typed descriptors instead of string key paths.</div></div></blockquote><div style="font-family: Helvetica; font-size: 15px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class=""></div><div style="font-family: Helvetica; font-size: 15px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">I understand this. But this is not like a lens. It is much more awkward to use.</div></div></blockquote><div><br class=""></div><div>I agree it is awkward. It is just a quick dump anyway. :)</div><div><br class=""></div><div>Expanding on Groff’s idea of a `T -> inout U`-ish lens, perhaps the reflection API can reside in the metatype, and create lenses (with runtime type checking) instead? It would end up similarly to Zheng’s initial idea. But unlike Zheng’s view types, lenses would not capture but expects an instance as its input.</div><div><br class=""></div><div>By the way, a read-write lens should be conceptually `inout T -> inout U` to cover also the value types. But then it would prevent it to be used with constant references (e.g. `self` in instance methods). New compiler magics can be engineered to tackle this though, or a distinction between a read-write lens for value type and reference type has to be made.</div><div><br class=""></div><div><br class=""></div><div>-</div><div>Note:</div><div>[swift-evolution] Proposal: Expose getter/setters in the same way<span class="Apple-tab-span" style="white-space: pre;"> </span>as regular methods</div><span class=""></span><span class=""><a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151214/003008.html" class="">https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151214/003008.html</a><br class=""></span><span class=""><br class=""></span><span class=""><br class=""></span><blockquote type="cite" class=""><div class=""><br class="" style="font-family: Helvetica; font-size: 15px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><blockquote type="cite" class="" style="font-family: Helvetica; font-size: 15px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div class=""><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-ligatures: normal; font-variant-position: normal; font-variant-caps: normal; font-variant-numeric: normal; font-variant-alternates: normal; font-variant-east-asian: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br class=""></div><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-ligatures: normal; font-variant-position: normal; font-variant-caps: normal; font-variant-numeric: normal; font-variant-alternates: normal; font-variant-east-asian: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">Anyway, the most important message I'd like to raise is that the mutation should be acted upon the owner of the property, if the reflection is supposed to cover also value types.</div></div></blockquote><blockquote type="cite" class="" style="font-family: Helvetica; font-size: 15px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div class=""><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-ligatures: normal; font-variant-position: normal; font-variant-caps: normal; font-variant-numeric: normal; font-variant-alternates: normal; font-variant-east-asian: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br class=""></div><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-ligatures: normal; font-variant-position: normal; font-variant-caps: normal; font-variant-numeric: normal; font-variant-alternates: normal; font-variant-east-asian: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">Specifically using Zheng’s initial idea as an example, the setter in “<span class="" style="background-color: rgb(255, 255, 255);"><font color="#333333" face="Consolas, Liberation Mono, Menlo, Courier, monospace" class=""><span class="" style="font-size: 12px; white-space: pre;">GetSetPropertyView”</span></font> of a property in a struct instance should not cause any change to the original instance by the established behaviour of value types in Swift.</span></div><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-ligatures: normal; font-variant-position: normal; font-variant-caps: normal; font-variant-numeric: normal; font-variant-alternates: normal; font-variant-east-asian: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><span class="" style="background-color: rgb(255, 255, 255);"><br class=""></span></div><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-ligatures: normal; font-variant-position: normal; font-variant-caps: normal; font-variant-numeric: normal; font-variant-alternates: normal; font-variant-east-asian: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><span class="" style="background-color: rgb(255, 255, 255);">Let’s say even If there are some kind of pointer </span>magic bypassing the value type restrictions at runtime, <span class="" style="color: rgb(51, 51, 51); font-family: Consolas, 'Liberation Mono', Menlo, Courier, monospace; font-size: 12px; white-space: pre; background-color: rgb(255, 255, 255);">GetSetPropertyView </span><span class="" style="background-color: rgb(255, 255, 255);">cannot be escaped but only useable in the local scope.</span><span class="" style="background-color: rgb(255, 255, 255);"> </span><span class="" style="background-color: rgb(255, 255, 255);">Otherwise, we would have a view that can somehow point to nothing. This doesn’t sound great either way.</span></div><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-ligatures: normal; font-variant-position: normal; font-variant-caps: normal; font-variant-numeric: normal; font-variant-alternates: normal; font-variant-east-asian: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><span class="" style="background-color: rgb(255, 255, 255);"><br class=""></span></div></div></blockquote><div style="font-family: Helvetica; font-size: 15px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class=""></div><div style="font-family: Helvetica; font-size: 15px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">You raise good points here. I am interested to hear what Joe Groff has to say about this. I believe the issues involved are the same as those involved with lenses into value types.</div><br class="" style="font-family: Helvetica; font-size: 15px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><blockquote type="cite" class="" style="font-family: Helvetica; font-size: 15px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div class=""><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-ligatures: normal; font-variant-position: normal; font-variant-caps: normal; font-variant-numeric: normal; font-variant-alternates: normal; font-variant-east-asian: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br class=""></div><blockquote type="cite" class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-ligatures: normal; font-variant-position: normal; font-variant-caps: normal; font-variant-numeric: normal; font-variant-alternates: normal; font-variant-east-asian: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div class=""><div dir="auto" class=""><div class=""><blockquote type="cite" class=""><div class=""><div class=""><br class=""></div><div class=""><br class=""></div></div></blockquote><blockquote type="cite" class=""><div class=""><div class="">Best Regards</div><div class="">Anders</div><div class=""><br class=""></div><div class=""><div class=""><br class=""></div><div class=""><div class=""><div class=""><div class=""><div class=""><blockquote type="cite" class=""><div class="">On 27 May 2016, at 9:25 AM, Austin Zheng via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Hi swift-evolution,<div class=""><br class=""></div><div class="">For those who are interested I'd like to present a pre-pre-proposal for reflection upon a type's properties and solicit feedback. </div><div class=""><br class=""></div><div class="">First of all, some caveats: this is only a very small piece of what reflection in Swift might look like one day, and it's certainly not the only possible design for such a feature. Reflection comes in many different forms, and "no reflection" 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'm not really interested in<span class="Apple-converted-space"> </span><i class="">defending</i> this specific proposal per se, as I am looking for a jumping-off point to explore designs in this space.</div><div class=""><br class=""></div><div class="">Anyways, here is a gist outlining the public API to the feature: </div><div class=""><br class=""></div><div class=""><a href="https://gist.github.com/austinzheng/699d47f50899b88645f56964c0b7109a" class="">https://gist.github.com/austinzheng/699d47f50899b88645f56964c0b7109a</a><br class=""></div><div class=""><br class=""></div><div class="">A couple of notes regarding the proposal:</div><div class=""><br class=""></div><div class="">The API names need improvement. Suggestions welcome.</div><div class=""><br class=""></div><div class="">It'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 class=""><br class=""></div><div class="">It uses "views": 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 class=""><br class=""></div><div class="">(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't care about setting, though, you can just work exclusively with get-only views.)</div><div class=""><br class=""></div><div class="">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 "untyped" 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 class=""><br class=""></div><div class="">The requirements part of it is composable. For example, you can imagine a future "FullyReflectable" protocol that simply inherits from "PropertyReflectable", "MethodReflectable", 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 "PropertyReflectable" and naturally enforce reflection support on the necessary types.</div><div class=""><br class=""></div><div class="">It looks a bit cumbersome, but there's room for refinement. Users won't necessarily see all the types, though, and the interface is pretty straightforward:</div><div class=""><br class=""></div><div class="">```</div><div class="">myPerson.typedReadWriteProperty<Int>("age")?.set(30)</div><div class=""><br class=""></div><div class="">try myPerson.allNamedProperties["age"]?.set(30)</div><div class="">```</div><div class=""><br class=""></div><div class="">I'm not yet sure how it should interact with access control (my inclination is that it would only expose the properties you'd be able to directly access), or property behaviors (I think get-set behavior is fundamental to properties, although "behavior metadata" on the views might be useful).</div><div class=""><br class=""></div><div class="">I'd also have to figure out how it would operate with generic types or existentials.</div><div class=""><br class=""></div><div class="">Anyways, thanks for reading all the way to the end, and any feedback, criticism, or alternative proposals would be greatly appreciated.</div><div class=""><br class=""></div><div class="">Best,</div><div class="">Austin</div></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class=""></div></div></div></div></div></div></blockquote><blockquote type="cite" class=""><div class=""><span class="">_______________________________________________</span><br class=""><span class="">swift-evolution mailing list</span><br class=""><span class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a></span><br class=""><span class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span></div></blockquote></div></div></div></blockquote></div></blockquote></div></blockquote></div><br class=""></body></html>