<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=""><br class=""><div><blockquote type="cite" class=""><div class="">On Feb 19, 2016, at 9:07 PM, Curt Clifton <<a href="mailto:curt@omnigroup.com" class="">curt@omnigroup.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="content-type" content="text/html; charset=utf-8" class=""><div dir="auto" class=""><div class=""><div class=""><br class=""></div>On Feb 19, 2016, at 10:21 AM, Joe Groff via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Feb 18, 2016, at 9:01 PM, Curt Clifton <<a href="mailto:curt@curtclifton.net" class="">curt@curtclifton.net</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">I find the naked `initialValue` “declaration" quite odd. It’s not exactly a declaration even. What are the implications for parsing? If we’re already willing to special case`initialValue` in the parser in this context, perhaps we could introduce a binding list instead, like:</div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class=""></div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">```</div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div class="">public var behavior lazy<Value>: Value {</div><div class=""> // Behaviors can bind the property's initializer expression with a</div><div class=""> // binding declaration.</div><div class=""> bind initialValue</div><div class=""> …</div></div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">```</div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">Besides eliminating the odd naked “declaration”, this has the added advantage that it could be extended to `bind initialValue, propertyName`. :-)</div></div></blockquote></div><br class=""><div class="">Yeah, I'm not happy with it either. An alternative might be to bless a specifically-named `accessor` declaration, e.g.:</div><div class=""><br class=""></div><div class="">var behavior lazy<Value>: Value {</div><div class=""> accessor initialValue() -> Value</div><div class="">}</div><div class=""></div></div></blockquote><blockquote type="cite" class=""><div class=""><br class=""></div></blockquote><br class=""><div class="">Maybe we're approaching this from the wrong direction. We already have some magic identifiers within behavior declarations as described in Bindings within Behavior Declarations: `Self` for the property's host type, `self` for the property's host instance, and `newValue` as the r-value in the implementation of the `set` core accessor.</div><div class=""><br class=""></div><div class="">What's to keep us from just treating `initialValue` as similar magic within a behavior declaration? Is it a matter of not wanting to use additional storage if the initial value isn't referenced? If so, it seems like that could be treated as a post-hoc optimization. (Hmm, I suppose this might have resilience issues since changing implementation would change requirements, unless "<span style="background-color: rgba(255, 255, 255, 0);" class="">we consider behaviors to be essentially always fragile" as mentioned in Future Directions.</span>)</div><div class=""><br class=""></div><div class="">Or is the concern that we must communicate to users of the behavior that a property so annotated must have an in-line initializer? That's implied by the formal grammar in the proposal, where the declaration is named `<span style="background-color: rgba(255, 255, 255, 0);" class="">initial-value-requirement-decl`. </span>If that's the case, then I'd take the blessed accessor alternative over a naked `initialValue` declaration. For regularity, in that world it seems like properties should be able to implement the accessor directly. That is:</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>@lazy var foo: Int = 4</div><div class=""><br class=""></div><div class="">and</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>@lazy var foo {</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span> initialValue { return 4 }</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>}</div><div class=""><br class=""></div><div class="">should be equivalent.</div><div class=""><br class=""></div><div class="">If that's distasteful, I'd make a pitch for:</div><div class=""><br class=""></div><div class=""><span style="background-color: rgba(255, 255, 255, 0);" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>initial-value-requirement-decl ::= 'requires' 'initialValue'</span></div><div class=""><span style="background-color: rgba(255, 255, 255, 0);" class=""><br class=""></span></div><div class=""><span style="background-color: rgba(255, 255, 255, 0);" class="">But I'll try to stop bike shedding this syntax now. I continued to be thrilled with the proposal and the directions in which behaviors can evolve.</span></div></div></div></blockquote><br class=""></div><div>We could conceivably infer the intended initial value semantics from the behavior's implementation, but in Swift we generally try to keep interfaces explicit. Whether an initial value is required and when it's evaluated are important parts of how you use the behavior. Even if we inferred the initial value semantics from the implementation, we would still need a way to express the semantics in the behavior's interface when it's printed from other modules.</div><div><br class=""></div><div>-Joe</div><br class=""></body></html>