<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=""><div class="">Hi Joe,</div><div class=""><br class=""></div><div class="">My overall impression is that this is moving in the right direction and getting close. It is going to be a great feature! The declaration syntax makes is much more clear and also more scalable. </div><div class=""><br class=""></div><div class="">Many good questions have already come up so I’ll just focus on things that haven’t been discussed yet.</div><div class=""><br class=""></div><div class="">The proposal makes it clear when an initializer is <b class="">required</b> but is a little bit less clear about when it may be left off. Is this correct?</div><div class=""><br class=""></div><div class="">var [baseProp] x // no initializer, ok as long as base doesn't have init req?</div><div class="">var [initializerReqt] y // no initializer, error because of the initializer requirement?</div><div class=""><br class=""></div><div class="">Another thing that isn’t clear is what happens when a property with a behavior is set within the initializer of the containing type:</div><div class=""><br class=""></div><div class="">struct S {</div><div class=""> var [observed] s: String</div><div class=""> init(s: String) {</div><div class=""> // What happens here? Is the behaviors “set” accessor called? </div><div class=""> // This may not always be desirable, as in the case of “observed"</div><div class=""> self.s = s</div><div class=""> }</div><div class="">}</div><div class=""><br class=""></div><div class="">One thought is that it might be good to allow behaviors to have `init` accessor that is used if the property is assigned by an initializer of the containing type (only the first time the property is assigned). This would clarify what happens during initialization of the containing type and allow for different init and set code paths when necessary. It would be distinguished from the behavior initializer by the lack of parens. If that is too subtle we could use a different name for the initialization accessor.</div><div class=""><br class=""></div><div class="">This would also allow us to support a variant `delayedImmutable` that *must* be assigned during initialization of the containing type, but not necessarily during phase 1. That behavior would facilitate maximum safety when we must pass `self` to the initializer when constructing an instance to assign to a property (not an uncommon use case). </div><div class=""><br class=""></div><div class="">If the compiler could enforce slightly relaxed initialization rules that require initialization of the property before the initializer exits and before the property is read in the initializer body, but not necessarily during phase 1, then we could achieve nearly complete static safety. The only window for error would be any uses of self that happen outside the initializer body before the property is initialized. </div><div class=""><br class=""></div><div class="">The behavior might look like this:</div><div class=""><br class=""></div><div class=""><div class="">public var behavior phase2Immutable<Value>: Value {</div><div class=""> private var value: Value? = nil</div><div class=""><br class=""></div><div class=""> get {</div><div class=""><div class=""> guard let value = value else {</div><div class=""> fatalError("property accessed before being initialized")</div><div class=""> }</div></div><div class=""> return value</div><div class=""> }</div><div class=""> </div><div class=""> init {</div><div class=""> value = initialValue</div><div class=""> }</div><div class="">}</div></div><div class=""><br class=""></div><div class="">This would be a significant improvement over delayedImmutable in many use cases IMO.</div><div class=""><br class=""></div><div class="">-Matthew</div><br class=""><div><blockquote type="cite" class=""><div class="">On Jan 13, 2016, at 4:07 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="">Thanks everyone for the first round of feedback on my behaviors proposal. I've revised it with the following changes:<br class=""><br class="">- Instead of relying on mapping behaviors to function or type member lookup, I've introduced a new purpose-built 'var behavior' declaration, which declares the accessor and initializer requirements and provides the storage and behavior methods of the property. I think this gives a clearer design for authoring behaviors, and allows for a more efficient and flexible implementation model.<br class="">- I've backed off from trying to include 'let' behaviors. As many of you noted, it's better to tackle immutable computed properties more holistically than to try to backdoor them in.<br class="">- I suggest changing the declaration syntax to use a behavior to square brackets—'var [behavior] foo'—which avoids ambiguity with destructuring 'var' bindings, and also works with future candidates for behavior decoration, particularly `subscript`.<br class=""><br class="">Here's the revised proposal:<br class=""><br class=""><a href="https://gist.github.com/jckarter/50b838e7f036fe85eaa3" class="">https://gist.github.com/jckarter/50b838e7f036fe85eaa3</a><br class=""><br class="">For reference, here's the previous iteration:<br class=""><br class="">https://gist.github.com/jckarter/f3d392cf183c6b2b2ac3<br class=""><br class="">Thanks for taking a look!<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=""></body></html>