<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=""><div class="">I've been meaning to review this one.</div><div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><ul class="" style="box-sizing: border-box; padding: 0px 0px 0px 2em; margin-top: 0px; margin-bottom: 16px; color: rgb(51, 51, 51); font-family: 'Helvetica Neue', Helvetica, 'Segoe UI', Arial, freesans, sans-serif, 'Apple Color Emoji', 'Segoe UI Emoji', 'Segoe UI Symbol'; font-size: 16px; background-color: rgb(255, 255, 255);"><li class="" style="box-sizing: border-box;">What is your evaluation of the proposal?</li></ul></div></blockquote><div class="">This is an excellent proposal.</div></div><div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><ul class="" style="box-sizing: border-box; padding: 0px 0px 0px 2em; margin-top: 0px; margin-bottom: 16px; color: rgb(51, 51, 51); font-family: 'Helvetica Neue', Helvetica, 'Segoe UI', Arial, freesans, sans-serif, 'Apple Color Emoji', 'Segoe UI Emoji', 'Segoe UI Symbol'; font-size: 16px; background-color: rgb(255, 255, 255);"><li class="" style="box-sizing: border-box;">Is the problem being addressed significant enough to warrant a change to Swift?</li></ul></div></blockquote><div class="">Yes. Actually, the "examples" within the proposal itself really only scratches the surface of the places I want to use this feature.</div></div><div class=""><br class=""></div><div class="">Swift's reflection system is pretty poor, supporting only read-only access. If I was writing a library to parse the options to `swiftc` for example, an application might want to declare a structure like</div><div class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class="">struct Options: String {</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>let applicationExtension : Bool</div><div class=""> let assertConfig: Bool</div><div class=""> let embedBitcodeMarker: Bool</div><div class=""> let emitBitcode: Bool</div><div class=""> //etc</div><div class="">}</div></blockquote><div class=""><br class=""></div><div class="">...and use this application-provided structure as part of the API itself. With clever use of Mirror, a library can reflect this structure, re-interpret the names under command-line-case-rules, and generate a parser that can read "-application-extension" "-assert-config" "embed-bitcode-marker" and so on.</div><div class=""><br class=""></div><div class="">However, while a library can <i class="">understand</i> this structure, it cannot <i class="">set the values</i> back on the structure defined by the application. Thus the application is doomed to work with a parse result object that has poor type information (such as a stringly-typed result). This basically negates the benefit of declaring a structure like this to begin with.</div><div class=""><br class=""></div><div class="">After this proposal, I can define a property behavior that relocates the variable storage to a stringly-typed underlying mechanism. As a result, I can construct a full-duplex bridge between "stringly-typed" access patterns and "statically-typed" access patterns, allowing me to alternate between one and the other as necessary. I can also get "writeable" reflection behavior. </div><div class=""><br class=""></div><div class="">I think the benefits of such a scheme (particularly as an opt-in mechanism, so as not to impact performance in general) is pretty endless. The API that I describe seems "obviously" the optimal API for practically any parse problem that terminates in a strongly typed structure (which is the case for most JSON, YAML, XML, CSV, CLI, and RPC-type application-layer problems), and under this proposal it becomes achievable.</div><div class=""><br class=""></div><div class="">One obvious extension I would like to see is "function behaviors" (a.k.a. decorators), but that is obviously a story for another proposal. Still, I would be really interested in studying in that direction in future proposals.</div><div class=""><br class=""></div><div class="">As others have mentioned, composeability is also interesting, but may not be entirely necessary for an initial pass at the feature. This seems like something that should be evaluated in the context of "so now we have two different libraries that each want their behavior on a property," which is a circumstance far removed from the present.</div><div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><ul class="" style="box-sizing: border-box; padding: 0px 0px 0px 2em; margin-top: 0px; margin-bottom: 16px; color: rgb(51, 51, 51); font-family: 'Helvetica Neue', Helvetica, 'Segoe UI', Arial, freesans, sans-serif, 'Apple Color Emoji', 'Segoe UI Emoji', 'Segoe UI Symbol'; font-size: 16px; background-color: rgb(255, 255, 255);"><li class="" style="box-sizing: border-box;">Does this proposal fit well with the feel and direction of Swift?</li></ul></div></blockquote><div class="">As explained above, the proposal can bridge an important problem; namely allowing dynamic behavior in a static type system. I think that this would allow clever library authors to design more Swift-like APIs.</div></div><div class=""><br class=""></div><div class=""><div class=""></div></div><blockquote type="cite" class=""><div class=""><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>• If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?</div></div></blockquote><div class=""><br class=""></div><div class="">I am familiar with function decorators in Python, which are a generalization of this scheme (they're composeable and they also work for functions). I miss decorators terribly in Swift. These are not quite as good, but they're a step.</div><div class=""><br class=""></div><div class=""><div class=""><blockquote type="cite" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>• How much effort did you put into your review? A glance, a quick reading, or an in-depth study?</blockquote><br class=""></div></div><div class="">I've tried to get to the meat of the proposal.</div><div class=""><br class=""></div><div class="">I'm deliberately avoiding the syntax bikeshed here–I'm much more interested in the behavior this proposal unlocks than the color of the paint. Paint the damn thing any color you like, but the underlying idea here is a really important step towards more dynamic kinds of runtime behaviors.</div><div class=""><br class=""></div><div class="">Drew</div><br class=""></body></html>