<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 May 27, 2016, at 9:50 AM, L Mihalkovic <<a href="mailto:laurent.mihalkovic@gmail.com" class="">laurent.mihalkovic@gmail.com</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: 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 4:05 PM, Matthew Johnson 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 class="" style="font-family: Helvetica; font-size: 12px; font-style: 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=""><br class="">Sent from my iPad</div><div class="" style="font-family: Helvetica; font-size: 12px; font-style: 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="">On May 26, 2016, at 9:44 PM, Austin Zheng <<a href="mailto:austinzheng@gmail.com" class="">austinzheng@gmail.com</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" class="" style="font-family: Helvetica; font-size: 12px; font-style: 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="ltr" class="">Thanks, as always, for the thoughtful feedback. (inline)<div class="gmail_extra"><br class=""><div class="gmail_quote">On Thu, May 26, 2016 at 7:20 PM, Matthew Johnson<span class="Apple-converted-space"> </span><span dir="ltr" class=""><<a href="mailto:matthew@anandabits.com" target="_blank" class="">matthew@anandabits.com</a>></span><span class="Apple-converted-space"> </span>wrote:<br class=""><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><div class="" style="word-wrap: break-word;"><div class=""><span class=""><br class=""><div class=""><br class=""></div></span><div class="">These names are a good place to start but I agree that it would be nice to improve them. I will give it some thought. One comment for now - you use both `get` / `set` and `read` / `write`. It’s probably better to pick one.</div></div></div></blockquote><div class=""><br class=""></div><div class="">Yes, that's a good start. I'll sleep on it.</div><div class=""> </div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><div class="" style="word-wrap: break-word;"><div class=""><span class=""><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><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></div></blockquote><div class=""><br class=""></div></span><div class="">What do you think of using the `deriving` syntax for this (assuming we go in that direction for Equatable, Hashable, and other synthesized conformances).</div></div></div></blockquote><div class=""><br class=""></div><div class="">'deriving' is pretty much what I had in mind. If Equatable gets a magical attribute, keyword, or whatever, I'd like to use it for this feature as well.</div><div class=""> </div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><div class="" style="word-wrap: break-word;"><div class=""><span class=""><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><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></div></blockquote><div class=""><br class=""></div></span><div class="">How did you arrive at `get` and `set` methods?</div></div></div></blockquote><div class=""><br class=""></div><div class="">One big advantage methods have over properties is that you can (as of right now) get a reference to a method as a value of function type, but not a property.</div></div></div></div></div></blockquote><div class="" style="font-family: Helvetica; font-size: 12px; font-style: 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><span class="" style="font-family: Helvetica; font-size: 12px; font-style: 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; float: none; display: inline !important;">True, but as with 'throws' this is a temporary limitation. I don't think we should design our reflection API around a temporary limitation. IIRC the intended plan for getting first class access to properties is a lens. If we model it as a property we will eventually get first class access to it as a lens (which means we play nice with lenses even though we don't know what they will look like yet).</span><div class="" style="font-family: Helvetica; font-size: 12px; font-style: 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=""></div><div class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class=""> </div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><div class="" style="word-wrap: break-word;"><div class=""><div class=""><br class=""></div><div class="">I am wondering how this might relate to lenses. If we’re going to introduce those it feels like the property value should be introduced as a lens. I’m unsure of exactly what that would look like but I it is definitely worth thinking about.</div></div></div></blockquote><div class=""><br class=""></div><div class="">I think it's worth consideration. Maybe views into properties can eventually conform to some sort of lens protocol or interface, allowing them to be composed and used as such.</div></div></div></div></div></blockquote><div class=""><br class=""></div><div class="">I think Joe Groff has talked about lenses more than anyone else. Maybe he has some thoughts on this. But as I noted above, maybe exposing access as a property is the best first step. It's easy enough to wrap in a closure if you need to pass a function around before property references / lenses are introduced.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class=""> </div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><div class="" style="word-wrap: break-word;"><div class=""><div class=""><br class=""></div>Another option if we don’t go with a lens is a simple property (`var value { get }` and `var value { get set }`). IIRC we are going to have throwing computed properties eventually so you could still throw from the setter.</div><div class=""><span class=""><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><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),<span class="Apple-converted-space"> </span></div></div></div></blockquote><div class=""><br class=""></div></span><div class="">This one is tricky. I am generally be opposed to any way to get around access control. But people are going to implement things like serialization using this which may require access to private properties. I think we want to try to understand the consequences of different options and when in doubt decide in favor caution.</div></div></div></blockquote><div class=""><br class=""></div><div class="">My personal preference would be to honor access control, and consider ser/de separately (especially since there are so many other possible considerations for that feature). Access control in Swift isn't just another safety feature, it's also a boundary for things like the optimizer.</div><div class=""><br class=""></div><div class="">To be honest, I expect the first big use of a feature like this to be turning JSON or XML received from a network call into model objects for an app. There are quite a few Objective-C libraries that use KVC to implement this functionality.</div></div></div></div></div></blockquote><div class=""><br class=""></div>As several have noted, this is what makes things tricky. People will want to write a library packaged as a module that can serialize private properties from types in a different module. We need to at least consider that use case. </div></div></div></blockquote><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: 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: 12px; font-style: normal; font-variant: 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: 12px; font-style: normal; font-variant: 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="">or perhaps simply read what the people who have a lot of experience the topic have to say about it, and hopefully learn from the errors others have described. Serialization has long been a source of serious security issues in Java. Swift could do without these</div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: 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: 12px; font-style: normal; font-variant: 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="">-1 </div></div></blockquote><br class=""></div><div>That’s a good point. Talking about the issues involved and stating the reasons for our decision is giving the use case consideration. I’m not advocating either way. I’m just saying that we need to make a conscious decision with a good and clearly stated rationale.</div><div><br class=""></div><div>-Matthew</div><br class=""></body></html>