<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="">Hi Joe,<div class=""><br class=""></div><div class="">I have a few of questions after reading your proposal.</div><div class=""><br class=""></div><div class=""><b class="">Question #1 : </b></div><div class=""><br class=""></div><div class="">Let’s say that the property behavior has an <span style="font-family: Consolas;" class="">init()</span> method as in your example for the <font face="Consolas" class="">lazy</font> property behavior where you simply assign <font face="Consolas" class="">nil</font> to the <font face="Consolas" class="">value</font>. After the declaration of the <font face="Consolas" class="">lazy</font> behavior you show how to use this behavior for a variable declared in the global scope, It appears to me that the <font face="Consolas" class="">init()</font> gets called at the time the property is declared because you mention in the comment that the property is inited to <font face="Consolas" class="">nil</font>:</div><div class=""><br class=""></div><div class=""><pre style="box-sizing: border-box; overflow: auto; font-family: Consolas, 'Liberation Mono', Menlo, Courier, monospace; margin-top: 0px; margin-bottom: 0px; line-height: 1.45; padding: 16px; background-color: rgb(247, 247, 247); border-top-left-radius: 3px; border-top-right-radius: 3px; border-bottom-right-radius: 3px; border-bottom-left-radius: 3px; word-wrap: normal; word-break: normal; color: rgb(51, 51, 51);" class=""><span class="pl-k" style="box-sizing: border-box; color: rgb(167, 29, 93);">var</span> [<span class="pl-k" style="box-sizing: border-box; color: rgb(167, 29, 93);">lazy</span>] x <span class="pl-k" style="box-sizing: border-box; color: rgb(167, 29, 93);">=</span> <span class="pl-c1" style="box-sizing: border-box; color: rgb(0, 134, 179);">1738</span> <span class="pl-c" style="box-sizing: border-box; color: rgb(150, 152, 150);">// Allocates an Int? behind the scenes, inited to nil</span>
</pre></div><div class=""><span class="pl-c" style="box-sizing: border-box; color: rgb(150, 152, 150);"><br class=""></span></div><div class="">My question is as follows: What about when the property is declared inside a class? At what point is the <font face="Consolas" class="">init()</font> called?</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><b class="">Question #2 :</b></div><div class=""><br class=""></div><div class="">In your example for the <font face="Consolas" class="">synchronized</font> property behavior, you have the following line of code in the declaration of the behavior:</div><div class=""><br class=""></div><div class=""><pre style="box-sizing: border-box; overflow: auto; font-family: Consolas, 'Liberation Mono', Menlo, Courier, monospace; margin-top: 0px; margin-bottom: 0px; line-height: 1.45; padding: 16px; background-color: rgb(247, 247, 247); border-top-left-radius: 3px; border-top-right-radius: 3px; border-bottom-right-radius: 3px; border-bottom-left-radius: 3px; word-wrap: normal; word-break: normal; color: rgb(51, 51, 51);" class=""> <span class="pl-k" style="box-sizing: border-box; color: rgb(167, 29, 93);">var</span> value: Value <span class="pl-k" style="box-sizing: border-box; color: rgb(167, 29, 93);">=</span> initialValue
</pre></div><div class=""><br class=""></div><div class="">The <font face="Consolas" class="">get</font> and the <font face="Consolas" class="">set</font> accessors use <font face="Consolas" class="">withLock { … }</font> to get / set the <font face="Consolas" class="">value</font>. However, the code above that stores the <font face="Consolas" class="">initialValue</font> in the <font face="Consolas" class="">value</font> variable does not use <font face="Consolas" class="">withLock { … }</font>. Does it matter? And similar to question #1, at what time is this code executed?</div><div class=""><br class=""></div><div class=""><b class=""><br class=""></b></div><div class=""><b class="">Comments About this Proposal:</b></div><div class=""><br class=""></div><div class="">I’ve been following the threads on property behaviors as it is one of my favorite threads. I don’t always understand everything that you are all saying, for example, I am not sure if I understand what you guys means by out-of-line initialization in this context. </div><div class=""><br class=""></div><div class="">In general, I like the proposal. At first I thought that the square brackets notation could be confusing as it looks like an array. I understand there aren’t many options to use. However, now that I think of this as a list of property behaviors preceding the property name, I think the square brackets are the right choice. </div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">Thank you</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><div><blockquote type="cite" class=""><div class="">On Jan 22, 2016, at 7:33 PM, Joe Groff 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="">I've revised my proposal again based on more feedback. Syntax changes include:<br class=""><br class="">- adopting John McCall's declaration-follows-use syntax for behavior declarations. I think this looks nice and provides a reasonable framework for binding all the fiddly bits of a property, such as its type, name, and initializer.<br class="">- changing the proposed syntax for behavior member lookup to 'property.[behavior].member', as suggested by Tal Atlas and others. I think this has a nice symmetry with the `var [behavior]` declaration syntax, and doesn't occupy any new sigils. On the other had, Curt Clifton and others have raised the point that it could be mistaken for a subscript at a glance.<br class=""><br class="">To reduce the complexity of the initial feature review, I've also removed many of the bells and whistles from this initial version for separate consideration. For now, I'm saying initializer requirements are always "eager" (can't refer to self) and always inline-initialized. This imposes some inconvenience on some use cases, but is an additive feature. I've also left behavior composition, extending behaviors, overloading behaviors, and name binding as future extensions. Joe Pamer raised some design and technical challenges around how type inference should work with behaviors too, which I think deserve focused discussion, so I'm sidestepping those issues by starting out saying properties with behaviors always need an explicit type. Here's the updated proposal:<br class=""><br class=""><a href="https://gist.github.com/jckarter/66ae8fb361c0d57b3227" class="">https://gist.github.com/jckarter/66ae8fb361c0d57b3227</a><br class=""><br class="">And for reference, previous iterations:<br class=""><br class="">https://gist.github.com/jckarter/50b838e7f036fe85eaa3<br class="">https://gist.github.com/jckarter/f3d392cf183c6b2b2ac3<br class=""><br class="">-Joe<br class="">_______________________________________________<br class="">swift-evolution mailing list<br class="">swift-evolution@swift.org<br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></div></blockquote></div><br class=""></div></body></html>