<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="">On Feb 11, 2016, at 10:30 AM, Joe Groff <<a href="mailto:jgroff@apple.com" class="">jgroff@apple.com</a>> wrote:<div><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><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></div></div></blockquote><div class=""><br class=""></div><div class="">Agreed.</div></div></div></div></blockquote><div><br class=""></div>WFM.</div><div><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=""><div class=""><br class=""><blockquote type="cite" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><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></div></blockquote><div class=""><br class=""></div><div class="">I think we should subset 'let' behaviors out for the same reason we don't yet allow computed 'let' properties—right now 'let' guarantees immutability, and we don't have a way in the language to enforce that for user code. It would definitely be nice to be able to declare 'let [delayed]' and 'var [delayed]', though.</div></div></div></div></blockquote><div><br class=""></div>Ok, I’m fine with starting small and generalizing over time.</div><div><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=""><div class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><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></div></div></blockquote><div class=""><br class=""></div>Yeah, this is more like what I had proposed in previous drafts. If we go this route, I would rather use special contextual declarators like this than '@initial_value_required'-like attributes.</div></div></div></blockquote><div><br class=""></div><div>Agreed. Where do you stand on taking behavior as a keyword? Do you prefer something like the example above, or something like what you wrote in your proposal?</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=""><div class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class=""><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></div></div></blockquote><div class=""><br class=""></div><div class="">As proposed there is no 'init(value: Value)'; we can design that later. An 'init()' with no arguments would always run at initialization time, as if:</div><div class=""><br class=""></div></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class=""><div class="">var [behavior] x: Int</div><div class=""><br class=""></div></div></blockquote>instantiated storage like:<div class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class="">var `x.[behavior].storage`: BehaviorStorage<Int> = `[behavior].init()`</div></blockquote></div></div></blockquote><div><br class=""></div>Makes sense!</div><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=""><div class=""><div class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><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></div></div></div></blockquote><div class=""><br class=""></div><div class="">In the proposal, I say it behaves like a get-only property—it evaluates every time it's loaded.</div></div></div></div></div></blockquote><div><br class=""></div>Ok, that semantic makes sense to me. Given that, a behavior can emulate any of the other semantics it wants.</div><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=""><div class=""><div class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class=""><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></div></div></blockquote><div class=""><br class=""></div>Yeah. DI-like initialization is one of the future directions.<br class=""></div></div></div></div></blockquote><div><br class=""></div>Ok. That means that we can’t actually cut @NSCopying over to it yet, but I’m fine with tackling that later.</div><div><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=""><div class=""><div class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class=""><br class=""></div><div class=""><div class="">This makes me vaguely uncomfortable, given that “changeObserved” has undeclared type requirements that are only diagnosed when the behavior is instantiated.</div></div></div></div></div></blockquote><div class=""><br class=""></div><div class="">That was an oversight. In reality you'd have to declare:</div><div class=""><br class=""></div><div class="">public behavior var [changeObserved] _: Value = initialValue</div><div class=""> where Value: Equatable {</div></div></div></div></div></blockquote><div><br class=""></div><div>Ok, great.</div><div><br class=""></div><div>I’m very curious where you stand on the syntax of the behavior decl, because this decl (as one concrete example) seems like it would be *much* nicer as:</div><div><br class=""></div><div>public var behavior changeObserved<Value : Equatable> {</div><div><br class=""></div><blockquote type="cite" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class=""><blockquote type="cite" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class="">Can property requirements in protocols have behaviors on them?</div></div></div></blockquote>I think not.</div></div></div></blockquote></div><br class=""><div class="">Ok, please mention that, thanks!</div><div class=""><br class=""></div><div class="">-Chris</div></body></html>