<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><br></div><div>On Feb 15, 2016, at 8:04 PM, Wallacy via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>&gt; wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr">In the last mail a mean, this:<div><div>a<b>#lazy.</b>clear()</div><div>b<b>#observable.</b>addObserver()</div><div><br></div><div>I forgot the name of the behavior. ;)</div></div></div></div></blockquote><div><br></div>Maybe that is a bad prognosis for this feature. The more the discussion progresses, the complex it becomes and the worse the syntax becomes.&nbsp;<div><br></div><div>Myles<br><div><br><div><blockquote type="cite"><div><div dir="ltr"><div><div>Syntax can be discussed in another thread anyway.</div><div><br></div><div>__</div><div><br></div><div>Just a question, there any plan to discuss some candidates as "default" behaviour on Swift 3 time-frame? Like 'lazy', 'observable', etc?</div><div><br></div><div>And some this "future work" like "Composing behaviors"?<br></div><div><br></div><div><div>I ask this because, knowing that we can use some of the functionality in time to propose improvements even before finalizing the version will help us suggest adjustments and reinforces the idea of a very simple initial proposal.<br></div><div><br></div></div></div></div><br><div class="gmail_quote"><div dir="ltr">Em seg, 15 de fev de 2016 às 21:26, Drew Crawford via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>&gt; escreveu:<br></div><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've been meaning to review this one.</div><div><br></div><div></div></div><div style="word-wrap:break-word"><div><blockquote type="cite"><div style="word-wrap:break-word"><ul style="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>What is your evaluation of the proposal?</li></ul></div></blockquote></div></div><div style="word-wrap:break-word"><div><div>This is an excellent proposal.</div></div><div><br></div><div></div></div><div style="word-wrap:break-word"><div><blockquote type="cite"><div style="word-wrap:break-word"><ul style="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>Is the problem being addressed significant enough to warrant a change to Swift?</li></ul></div></blockquote></div></div><div style="word-wrap:break-word"><div><div>Yes.&nbsp; Actually, the "examples" within the proposal itself really only scratches the surface of the places I want to use this feature.</div></div><div><br></div><div>Swift's reflection system is pretty poor, supporting only read-only access.&nbsp; 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><br></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div>struct Options: String {</div><div><span style="white-space:pre-wrap">        </span>let applicationExtension : Bool</div><div>&nbsp; &nbsp; &nbsp; &nbsp; let assertConfig: Bool</div><div>&nbsp; &nbsp; &nbsp; &nbsp; let embedBitcodeMarker: Bool</div><div>&nbsp; &nbsp; &nbsp; &nbsp; let emitBitcode: Bool</div><div>&nbsp; &nbsp; &nbsp; &nbsp;//etc</div><div>}</div></blockquote><div><br></div><div>...and use this application-provided structure as part of the API itself.&nbsp; 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><br></div><div>However, while a library can <i>understand</i>&nbsp;this structure, it cannot <i>set the values</i>&nbsp;back on the structure defined by the application.&nbsp; Thus the application is doomed to work with a parse result object that has poor type information (such as a stringly-typed result).&nbsp; This basically negates the benefit of declaring a structure like this to begin with.</div><div><br></div><div>After this proposal, I can define a property behavior that relocates the variable storage to a stringly-typed underlying mechanism.&nbsp; 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.&nbsp; I can also get "writeable" reflection behavior. &nbsp;</div><div><br></div><div>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.&nbsp; 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><br></div><div>One obvious extension I would like to see is "function behaviors" (a.k.a. decorators), but that is obviously a story for another proposal.&nbsp; Still, I would be really interested in studying in that direction in future proposals.</div><div><br></div><div>As others have mentioned, composeability is also interesting, but may not be entirely necessary for an initial pass at the feature.&nbsp; 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><br></div><div></div></div><div style="word-wrap:break-word"><div><blockquote type="cite"><div style="word-wrap:break-word"><ul style="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>Does this proposal fit well with the feel and direction of Swift?</li></ul></div></blockquote></div></div><div style="word-wrap:break-word"><div><div>As explained above, the proposal can bridge an important problem; namely allowing dynamic behavior in a static type system.&nbsp; I think that this would allow clever library authors to design more Swift-like APIs.</div></div><div><br></div><div><div></div></div><blockquote type="cite"><div><div><span style="white-space:pre-wrap">        </span>• If you have used other languages or libraries with a similar feature, how do you feel that&nbsp;this proposal compares to those?</div></div></blockquote><div><br></div><div>I am familiar with function decorators in Python, which are a generalization of this scheme (they're composeable and they also work for functions).&nbsp; I miss decorators terribly in Swift.&nbsp; These are not quite as good, but they're a step.</div><div><br></div><div><div><blockquote type="cite"><span style="white-space:pre-wrap">        </span>• How much effort did you put into your review? A glance, a quick reading, or an in-depth&nbsp;study?</blockquote><br></div></div><div>I've tried to get to the meat of the proposal.</div><div><br></div><div>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.&nbsp; 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><div style="word-wrap:break-word"><div><br></div><div>Drew</div><br></div>_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</blockquote></div>
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></div></div></div></body></html>