<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=""><blockquote type="cite" class=""><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></blockquote><div class="">I agree with a number of people that have already replied before me: I think this is a very exiting proposal, but as it is right now, its not 100% fleshed out. Chris and other already provided comments on a number of points that also came to my mind. Specifically, I am not very keen on the proposed v.[foo] syntax and also the declaration of behaviours looks off to me as well (even though its elegant in its own right). I’d prefer something like</div><div class=""><br class=""></div><div class="">property behavior foo<valueType: Value, instanceType: Self where …> {</div><div class=""><br class=""></div><div class="">}</div><div class=""><br class=""></div><div class="">e.g. where we take the already available generics syntax and extend it with arguments to signal that behaviours are generics over multiple specific dimensions (this can be also used for a future extension of generic types). Required initial value can be coded by a presence of a constructor that takes mandatory argument, for example, or by an attribute as Chris suggests.</div><div class=""><br class=""></div><div class="">One potential problem with a feature like this is that it is very fundamental —it affects many areas of the language, some of those in a non-trivial way. These things are hard to get from the first go. I’d suggest that one makes an experimental implementation first and lets a bunch of people test-drive it for a couple of weeks or even months. I am sure that there will be some subtle design decisions that one might regret later. </div><div class=""><br class=""></div><div class="">So yes, its a definitive +1 but of the kind “revise and resubmit”. Also, sole real-world testing should be done before feature like this is be accepted into the core language. I also believe that fundamental, non-trivial features like these are best designed in a team. </div><div class=""><br class=""></div><blockquote type="cite" class=""><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></blockquote><div class="">Yes. it makes the language more consistent and flexible, while removing idiosyncrazy. I am also sure that it will open up new possibilities for the UI framework teams to come up with great APIs :)</div><br class=""><blockquote type="cite" class=""><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></blockquote><div class="">Yes, definitely </div><br class=""><blockquote type="cite" class=""><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;">If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?</li></ul></blockquote><div class="">I have used Python that has a very similar feature (property descriptors) quite extensively, and I have implemented many different patterns using this mechanism (such as property observing and binding). I have also implemented something similar for R. I believe that Joe’s proposal is much better thought out and fits the overall theme of a strongly typed language very well. </div><br class=""><blockquote type="cite" class=""><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;">How much effort did you put into your review? A glance, a quick reading, or an in-depth study?</li></ul></blockquote><div class="">A quick reading. I was also following the discussion, but its a bit difficult to keep up — watching the swift-evolution list is more like a full-time job :)</div><div class=""><br class=""></div><div class="">— Taras</div><div class=""><br class=""></div><div><blockquote type="cite" class=""><div class="">On 11 Feb 2016, at 07:13, Chris Lattner 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=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">On Feb 10, 2016, at 2:00 PM, Douglas Gregor via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><div class=""><blockquote type="cite" class=""><span style="color: rgb(119, 119, 119); 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);" class="">Proposal link:</span><br class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><blockquote style="box-sizing: border-box; margin: 0px 0px 16px; padding: 0px 15px; color: rgb(119, 119, 119); border-left-width: 4px; border-left-style: solid; border-left-color: rgb(221, 221, 221); 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);" class=""><blockquote style="box-sizing: border-box; margin: 0px 0px 16px; padding: 0px 15px; border-left-width: 4px; border-left-style: solid; border-left-color: rgb(221, 221, 221);" class=""><div style="box-sizing: border-box; margin-top: 0px; margin-bottom: 0px;" class=""><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0030-property-behavior-decls.md" class="">https://github.com/apple/swift-evolution/blob/master/proposals/0030-property-behavior-decls.md</a></div></blockquote><p style="box-sizing: border-box; margin-top: 0px; margin-bottom: 16px;" class=""><a id="user-content-what-goes-into-a-review-1" class="anchor" href="https://github.com/apple/swift-evolution#what-goes-into-a-review-1" aria-hidden="true" style="font-size: 1em; box-sizing: border-box; color: rgb(64, 120, 192); text-decoration: none; display: inline-block; padding-right: 2px; margin-left: -18px; line-height: 1.1;"><svg aria-hidden="true" class="octicon octicon-link" height="16" role="img" version="1.1" viewBox="0 0 16 16" width="16"><path d="M4 9h1v1h-1c-1.5 0-3-1.69-3-3.5s1.55-3.5 3-3.5h4c1.45 0 3 1.69 3 3.5 0 1.41-0.91 2.72-2 3.25v-1.16c0.58-0.45 1-1.27 1-2.09 0-1.28-1.02-2.5-2-2.5H4c-0.98 0-2 1.22-2 2.5s1 2.5 2 2.5z m9-3h-1v1h1c1 0 2 1.22 2 2.5s-1.02 2.5-2 2.5H9c-0.98 0-2-1.22-2-2.5 0-0.83 0.42-1.64 1-2.09v-1.16c-1.09 0.53-2 1.84-2 3.25 0 1.81 1.55 3.5 3 3.5h4c1.45 0 3-1.69 3-3.5s-1.5-3.5-3-3.5z"></path></svg></a><span style="color: rgb(51, 51, 51); font-size: 1em;" class="">What goes into a review?</span></p></blockquote><p style="box-sizing: border-box; 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);" class="">The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:</p><ul 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);" class=""><li style="box-sizing: border-box;" class="">What is your evaluation of the proposal?</li></ul></div></div></blockquote><div class="">I’m +1 on the feature. I have some comments for discussion though, I’m sorry I didn’t get these to you before the formal proposal went out:</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">First, on the most obvious bikeshed, the surface level syntax proposed:</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>var [lazy] foo = 1738</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>foo.[lazy].clear()<br class=""><br class=""></div><div class=""><br class=""></div><div class="">Given the recent trend to use # for compiler synthesized / macroish / magic syntax, it is worth considering whether:</div><div class=""><br class=""></div><div class=""><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>var #lazy foo = 1738</div><div class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>foo.#lazy.clear()</div><div class=""><br class=""></div></div><div class="">might make sense, or even:</div><div class=""><br class=""></div><div class=""><div class=""><span class="Apple-tab-span" style="white-space: pre;"> </span> #lazy var foo = 1738</div><div class=""><br class=""></div></div><div class="">I think that something like this is a bit better aesthetically, since the [] delimiters are heavily array/collection/subscript-centric (which is a good thing). OTOH, this would be giving users access to the “#” namespace, which means that future conflicts would have to be resolved with backticks - e.g. if they wanted a “line” behavior, they’d have to use "var #`line` foo = 1738”. I guess the fact that we already have a solution to the imagined problem means that this isn’t a big concern in practice.</div><div class=""><br class=""></div><div class="">In any case, I think we should just pick a syntax, land the feature, and keep bikeshedding on it through the end of Swift 3 :-)</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">What are the semantics of behaviors applied to var/let decls with non-trivial patterns? For example:</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>var [lazy] (foo, bar) = qux()</div><div class=""><br class=""></div><div class="">? While we could devise semantics for this in some cases, I think it is reasonable to only allow behaviors on single-identifier patterns, and reject the other cases as invalid. If you agree, please loop that into the proposal.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">I understand the need to specifying whether the getter/setter and other random methods are mutating or not, but doesn’t this eliminate the difference between a var/let behavior? Couldn’t we just say that a behavior with a nonmutating getter & setter are valid on a “let”, and that any other mutating members are unavailable on a let? This seems like a theoretical win, though I’m not sure whether it would actually be a win in practice for any conceivable behaviors you’ve been thinking about.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">I like the approach of having a behavior decl, but am not excited about the decl syntax itself:</div><div class=""><pre style="box-sizing: border-box; overflow: auto; font-family: Consolas, 'Liberation Mono', Menlo, Courier, monospace; font-size: 14px; 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="">behavior <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>] _: Value <span class="pl-k" style="box-sizing: border-box; color: rgb(167, 29, 93);">=</span> initialValue {
</pre><div class=""><br class=""></div></div><div class="">I understand that this is intended to provide a template-like construct, but I have a few problems with this:</div><div class=""><br class=""></div><div class="">1) A number of the things here are actually totally invariant (e.g. the _, the colon) or only serve to provide a name (Value, initialValue) but cannot be expanded into general expressions, though they look like they are.</div><div class=""><br class=""></div><div class="">2) This is totally unprecedented in Swift. We have a very regular structure of “@attributes decl-modifiers introducer_keyword name” - we have no declarations that look like this. For example, while operator decls could follow this structure, they don’t.</div><div class=""><br class=""></div><div class="">3) If you agree that we don’t need to differentiate between var/let then “behavior var" is providing potentially misleading info.</div><div class=""><br class=""></div><div class="">IMO, the most regular decl structure would be:</div><div class=""><br class=""></div><div class="">@initial_value_required // or something like it.</div><div class="">property behavior lazy { // could be “subscript behavior” at some point in the future?</div><div class=""> var value: Self? = nil // Self is the property type? Seems weird if it is the enclosing type.</div><div class=""> ...</div><div class="">}</div><div class=""><br class=""></div><div class="">or perhaps:</div><div class=""><br class=""></div><div class=""><div class="">@initial_value_required</div><div class="">property behavior lazy<PropertyType> { // specify the type of the property as a generic constraint?</div><div class=""> var value: PropertyType? = nil </div><div class=""> ...</div><div class="">}</div><div class=""><br class=""></div></div><div class="">though I agree that this would require us to take “behavior” as a keyword. Do we know whether or not this would be a problem in practice? If so, going with “behavior var” and “behavior let” is probably ok.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">Of course, @initial_value_required is also pretty gross. The alternative is to follow the precedent of operator decls, and introduce random syntax in their body, such as:</div><div class=""><br class=""></div><div class=""><div class="">property behavior lazy<PropertyType> {</div><div class=""> initializer initValue</div><div class=""> var value: PropertyType? = nil </div><div class=""> …</div><div class=""> value = initValue</div><div class=""> ...</div><div class="">}</div><div class=""><br class=""></div></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><pre style="box-sizing: border-box; overflow: auto; font-family: Consolas, 'Liberation Mono', Menlo, Courier, monospace; font-size: 14px; 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-c" style="box-sizing: border-box; color: rgb(150, 152, 150);">// Behaviors can declare storage that backs the property.</span>
<span class="pl-k" style="box-sizing: border-box; color: rgb(167, 29, 93);">private</span> <span class="pl-k" style="box-sizing: border-box; color: rgb(167, 29, 93);">var</span> value: Value?
</pre><div class=""><br class=""></div></div><div class="">What is the full range of access control allowed here? Is there any reason to allow anything other than “public” (which would mean that the entity is exposed at whatever the properties access control level is)? If so, why allow specifying internal? For sake of exposition in the proposal, it seems simplest to say:</div><div class=""><br class=""></div><div class=""><pre style="box-sizing: border-box; overflow: auto; font-family: Consolas, 'Liberation Mono', Menlo, Courier, monospace; font-size: 14px; 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? // private by default</pre><div class=""><br class=""></div></div><div class="">or something.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><pre style="box-sizing: border-box; overflow: auto; font-family: Consolas, 'Liberation Mono', Menlo, Courier, monospace; font-size: 14px; 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-c" style="box-sizing: border-box; color: rgb(150, 152, 150);">// Behaviors can declare initialization logic for the storage.</span>
<span class="pl-c" style="box-sizing: border-box; color: rgb(150, 152, 150);">// (Stored properties can also be initialized in-line.)</span>
<span class="pl-k" style="box-sizing: border-box; color: rgb(167, 29, 93);">init</span>() {
value <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);">nil</span>
}</pre><div class=""><br class=""></div></div><div class="">If a behavior has an init() with no arguments, then are the semantics that it is *always* run? What if there are both an init() and an init(value : Value)?</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><pre style="box-sizing: border-box; overflow: auto; font-family: Consolas, 'Liberation Mono', Menlo, Courier, monospace; font-size: 14px; 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-c" style="box-sizing: border-box; color: rgb(150, 152, 150);">// Inline initializers are also supported, so `var value: Value? = nil`</span>
<span class="pl-c" style="box-sizing: border-box; color: rgb(150, 152, 150);">// would work equivalently.</span>
</pre><div class=""><span class="pl-c" style="box-sizing: border-box; color: rgb(150, 152, 150);"><br class=""></span></div><div class="">This example is using a stored property of type Optional<Value> which has a default value of nil, does that count or is this a syntactic requirement? To me, it seems most natural to follow the existing rules we have:</div><div class=""><br class=""></div><div class="">1) If you write any init, then you get what you write.</div><div class="">2) If there are no init’s, and any stored property in a behavior is non-default initializable, then it is an error.</div><div class="">3) If there are no init’s, and all stored properties in a behavior are default initializable, then you get init() implicitly.</div><div class=""><br class=""></div></div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">Typographical comment:</div><div class=""><pre style="box-sizing: border-box; overflow: auto; font-family: Consolas, 'Liberation Mono', Menlo, Courier, monospace; font-size: 14px; 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);">if</span> <span class="pl-k" style="box-sizing: border-box; color: rgb(167, 29, 93);">let</span> value <span class="pl-k" style="box-sizing: border-box; color: rgb(167, 29, 93);">=</span> value {
<span class="pl-k" style="box-sizing: border-box; color: rgb(167, 29, 93);">return</span> value
}
</pre><div class=""><br class=""></div><div class="">You have way too many “value”s floating around, for sake of clarity, how about:</div><div class=""><br class=""></div><div class=""><pre style="box-sizing: border-box; overflow: auto; font-family: Consolas, 'Liberation Mono', Menlo, Courier, monospace; font-size: 14px; 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);">if</span> <span class="pl-k" style="box-sizing: border-box; color: rgb(167, 29, 93);">let</span> valuePresent <span class="pl-k" style="box-sizing: border-box; color: rgb(167, 29, 93);">=</span> value {
<span class="pl-k" style="box-sizing: border-box; color: rgb(167, 29, 93);">return</span> valuePresent
}
</pre></div><div class=""><br class=""></div></div><div class=""><br class=""></div><div class="">In "Resettable properties”, you have this:</div><div class=""><br class=""></div><div class=""><pre style="box-sizing: border-box; overflow: auto; font-family: Consolas, 'Liberation Mono', Menlo, Courier, monospace; font-size: 14px; 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-c" style="box-sizing: border-box; color: rgb(150, 152, 150);">// Reset the property to its original initialized value.</span>
<span class="pl-k" style="box-sizing: border-box; color: rgb(167, 29, 93);">mutating</span> <span class="pl-k" style="box-sizing: border-box; color: rgb(167, 29, 93);">func</span> <span class="pl-en" style="box-sizing: border-box; color: rgb(121, 93, 163);">reset</span>() {
value <span class="pl-k" style="box-sizing: border-box; color: rgb(167, 29, 93);">=</span> initialValue
}</pre><div class=""><br class=""></div><div class="">This raises the question of how “initialValue” works: Is it evaluated once when the property is bound and the resultant value is stored somewhere (evaluating any side effects exactly once) or is it an auto-closure-like concept? If it is autoclosure-like, what does it mean in terms of requiring “self." qualification & @noescape?</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">In the context of your @NSCopying-replacement example, I would want something like this:</div><div class=""><br class=""></div><div class="">class Foo {</div><div class=""> var [copying] myproperty : NSString</div><div class=""><br class=""></div><div class=""> init(a : NSString) {</div><div class=""> myproperty = a</div><div class=""> }</div><div class="">}</div><div class=""><br class=""></div><div class="">to work, where the behavior requires an initial value, but that value is provided by a flow-sensitive initialization point by DI . How does this happen?</div></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><div class=""><span style="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);" class="">"This imposes an </span><strong style="box-sizing: border-box; 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;" class="">initializer requirement</strong><span style="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);" class=""> on the behavior. Any property using the behavior must be declared with an initial value"</span></div><div class=""><br class=""></div><div class="">Ah, this gets to the @NSCopying replacement example. This might be too limiting, but so long as there is a path forward to generalize this, it seems like a fine starting point.</div><div class=""><br class=""></div><div class="">[[Coming back to this after reading to the end]] Ok, I see this is in the future directions section. I’m fine with punting this to a further revision of the proposal, but I think that it is worthwhile to provide a syntactic affordance to differentiate properties that “must have an initializer expression” and “must be initialized by an 'init(v: Value)’ member on the behavior before otherwise used”. @NSCopying replacement seems like the later case. I’m fine with pushing off the general case to a later proposal, but we should carve out space for it to fit in.</div><div class=""><br class=""></div><div class=""><br class=""></div></div><div class=""><br class=""></div><div class=""><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><pre style="box-sizing: border-box; overflow: auto; font-family: Consolas, 'Liberation Mono', Menlo, Courier, monospace; font-size: 14px; 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);">public</span> behavior <span class="pl-k" style="box-sizing: border-box; color: rgb(167, 29, 93);">var</span> [changeObserved] _: Value <span class="pl-k" style="box-sizing: border-box; color: rgb(167, 29, 93);">=</span> initialValue {</pre><pre style="box-sizing: border-box; overflow: auto; font-family: Consolas, 'Liberation Mono', Menlo, Courier, monospace; font-size: 14px; 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);">if</span> oldValue <span class="pl-k" style="box-sizing: border-box; color: rgb(167, 29, 93);">!=</span> newValue {
</pre></div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">This makes me vaguely uncomfortable, given that “changeObserved” has undeclared type requirements that are only diagnosed when the behavior is instantiated. I’d greatly prefer to see something like:</div><div class=""><br class=""></div><div class=""><div class="">@initial_value_required</div><div class="">property behavior changeObserved<PropertyType : Equatable> { // constraint specified!</div></div><div class=""><br class=""></div><div class="">which would allow the behavior to be modularly type checked.</div><div class=""><br class=""></div><div class="">[[later…]] ah, I see that you’re doing something similar but different in the "Synchronized Property Access” example. I mostly care that we can express and modularly check this, the exact syntax isn’t as important.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">In detailed design:</div><div class=""><pre lang="text" style="box-sizing: border-box; overflow: auto; font-family: Consolas, 'Liberation Mono', Menlo, Courier, monospace; font-size: 14px; margin-top: 0px; margin-bottom: 16px; 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; color: rgb(51, 51, 51);" class=""><code style="box-sizing: border-box; font-family: Consolas, 'Liberation Mono', Menlo, Courier, monospace; padding: 0px; margin: 0px; background-color: transparent; border-top-left-radius: 3px; border-top-right-radius: 3px; border-bottom-right-radius: 3px; border-bottom-left-radius: 3px; word-break: normal; border: 0px; display: inline; line-height: inherit; word-wrap: normal;" class="">property-behavior-decl ::=
attribute* decl-modifier*
'behavior' 'var' '[' identifier ']' // behavior name
(identifier | '_') // property name binding
</code></pre></div><div class=""><div class="">If you go with this declaration syntax, I’d suggest requiring _ for the name, since the name isn’t otherwise used for anything. Ah, it looks like you say this later, maybe the grammar just needs to be updated?</div><div class=""><ul 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);" class=""><li style="box-sizing: border-box;" class="">A <code style="box-sizing: border-box; font-family: Consolas, 'Liberation Mono', Menlo, Courier, monospace; font-size: 14px; padding: 0.2em 0px; margin: 0px; background-color: rgba(0, 0, 0, 0.0392157); border-top-left-radius: 3px; border-top-right-radius: 3px; border-bottom-right-radius: 3px; border-bottom-left-radius: 3px;" class="">_</code> placeholder is required in the name position. (A future extension of behaviors may allow the property name to be bound as a string literal here.)</li></ul></div><div class=""><br class=""></div></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><span style="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);" class="">"Inside a behavior declaration, </span><code style="box-sizing: border-box; font-family: Consolas, 'Liberation Mono', Menlo, Courier, monospace; font-size: 14px; padding: 0.2em 0px; margin: 0px; background-color: rgba(0, 0, 0, 0.0392157); border-top-left-radius: 3px; border-top-right-radius: 3px; border-bottom-right-radius: 3px; border-bottom-left-radius: 3px; color: rgb(51, 51, 51);" class="">self</code><span style="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);" class=""> is implicitly bound to the value that contains the property instantiated using this behavior. For a freestanding property at global or local scope, this will be the empty tuple </span><code style="box-sizing: border-box; font-family: Consolas, 'Liberation Mono', Menlo, Courier, monospace; font-size: 14px; padding: 0.2em 0px; margin: 0px; background-color: rgba(0, 0, 0, 0.0392157); border-top-left-radius: 3px; border-top-right-radius: 3px; border-bottom-right-radius: 3px; border-bottom-left-radius: 3px; color: rgb(51, 51, 51);" class="">()</code><span style="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);" class="">, and for a static or class property, this will be the metatype. Within the behavior declaration, the type of </span><code style="box-sizing: border-box; font-family: Consolas, 'Liberation Mono', Menlo, Courier, monospace; font-size: 14px; padding: 0.2em 0px; margin: 0px; background-color: rgba(0, 0, 0, 0.0392157); border-top-left-radius: 3px; border-top-right-radius: 3px; border-bottom-right-radius: 3px; border-bottom-left-radius: 3px; color: rgb(51, 51, 51);" class="">self</code><span style="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);" class=""> is abstract and represented by the implicit generic type parameter </span><code style="box-sizing: border-box; font-family: Consolas, 'Liberation Mono', Menlo, Courier, monospace; font-size: 14px; padding: 0.2em 0px; margin: 0px; background-color: rgba(0, 0, 0, 0.0392157); border-top-left-radius: 3px; border-top-right-radius: 3px; border-bottom-right-radius: 3px; border-bottom-left-radius: 3px; color: rgb(51, 51, 51);" class="">Self</code><span style="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);" class="">."</span></div><div class=""><br class=""></div></div><div class="">This is somewhat strange to me. Would it be reasonable to say that self is bound iff the behavior has a classbound requirement on Self? Alternatively, perhaps you could somehow declare/name the declcontext type, and refer to it later by a name other than Self?</div><div class=""><br class=""></div><div class=""><pre style="box-sizing: border-box; overflow: auto; font-family: Consolas, 'Liberation Mono', Menlo, Courier, monospace; font-size: 14px; 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);">mutating</span> <span class="pl-k" style="box-sizing: border-box; color: rgb(167, 29, 93);">func</span> <span class="pl-en" style="box-sizing: border-box; color: rgb(121, 93, 163);">update</span>(x: <span class="pl-c1" style="box-sizing: border-box; color: rgb(0, 134, 179);">Int</span>) {
[foo]<span class="pl-k" style="box-sizing: border-box; color: rgb(167, 29, 93);">.</span>x <span class="pl-k" style="box-sizing: border-box; color: rgb(167, 29, 93);">=</span> x <span class="pl-c" style="box-sizing: border-box; color: rgb(150, 152, 150);">// Disambiguate reference to behavior storage</span>
}
</pre><div class=""><br class=""></div><div class="">It would be really nice to be able to keep “self” referring to the behavior, and require an explicit declaration for the enclosing declaration if a behavior requires one (e.g. in the case of atomic).</div></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><span style="background-color: rgb(255, 255, 255);" class="">"</span><span style="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: 1.5em; background-color: rgb(255, 255, 255);" class="">Nested Types in Behaviors</span><font color="#333333" face="Helvetica Neue, Helvetica, Segoe UI, Arial, freesans, sans-serif, Apple Color Emoji, Segoe UI Emoji, Segoe UI Symbol" size="4" class="">”</font></div><div class=""><span style="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: 1.5em; background-color: rgb(255, 255, 255);" class=""><br class=""></span></div><div class="">This sounds great in the fullness of time, but it seems subsettable out of the first implementation/proposal. Lacking this, it can be easily worked around with a private peer type.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><pre style="box-sizing: border-box; overflow: auto; font-family: Consolas, 'Liberation Mono', Menlo, Courier, monospace; font-size: 14px; 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-c" style="box-sizing: border-box; color: rgb(150, 152, 150);">// Parameter gets the name 'bas' from the accessor requirement</span>
<span class="pl-c" style="box-sizing: border-box; color: rgb(150, 152, 150);">// by default, as with built-in accessors today.</span>
</pre><div class=""><span class="pl-c" style="box-sizing: border-box; color: rgb(150, 152, 150);"><br class=""></span></div><div class=""><span class="pl-c" style="box-sizing: border-box; color: rgb(150, 152, 150);"><br class=""></span></div><div class=""><span class="pl-c" style="box-sizing: border-box;">Not really important for the v1 proposal, but it seems like a natural direction to allow this to be controlled by “API names” in the accessor. The default would be that there are no API names, but if a behavior specified one, e.g.:</span></div><div class=""><span class="pl-c" style="box-sizing: border-box;"><br class=""></span></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>willSet(newValue newValue : Value) </div></div><div class=""><br class=""></div><div class="">then “newValue” would be the default name in the body of the accessor. If no “API name” were specified, then no name would be default injected.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">Typographical comment w.r.t. the "// Reinvent computed properties” example, you refer to the behavior as both “foobar” and “computed” later, I think the later reference is supposed to be "var [foobar] bar: Int”? Feel free to find more diversity in your metasyntactic names here :-)</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><p style="box-sizing: border-box; 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);" class="">"Accessor requirements cannot take visibility modifiers; they are always as visible as the behavior itself."</p><div class="">Maybe I’m misinterpreting this, but I see accessors differently. I see them as “never being accessible to the code that declares a property using the behavior”. If you want this, you can define a method that wraps them or something. To a client of a behaviors, accessors are “implementation only”.</div><div class=""><br class=""></div><div class=""><br class=""></div></div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">Can property requirements in protocols have behaviors on them?</div><div class=""><br class=""></div><div class=""><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><ul 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);" class=""><li style="box-sizing: border-box;" class="">Is the problem being addressed significant enough to warrant a change to Swift?</li></ul></div></div></blockquote><div class="">Yep.</div><div class=""><br class=""></div><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><ul 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);" class=""><li style="box-sizing: border-box;" class="">Does this proposal fit well with the feel and direction of Swift?</li></ul></div></div></blockquote><div class=""><div class="">Yep, moving generalizing special case hacks and moving them out of the compiler is a great direction.</div><div class=""><br class=""></div></div><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><ul 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);" class=""><li style="box-sizing: border-box;" class="">If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?</li></ul></div></div></blockquote><div class="">I have not.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><ul 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);" class=""><li style="box-sizing: border-box;" class="">How much effort did you put into your review? A glance, a quick reading, or an in-depth study?</li></ul></div></div></blockquote>I’m spent a lot of time following the discussion and chatting with Joe about this periodically, starting when Dmitri pointed out this possible direction back in Dec 2014. :-)</div><div class=""><br class=""></div><div class="">-Chris</div><br class=""></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></body></html>