<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 Jan 20, 2016, at 11:39 AM, Joe Groff <<a href="mailto:jgroff@apple.com" class="">jgroff@apple.com</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=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Jan 20, 2016, at 9:31 AM, Matthew Johnson <<a href="mailto:musical.matthew@mac.com" class="">musical.matthew@mac.com</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="">Joe, <div class=""><br class=""></div><div class="">I’m wondering if you missed my comments. I had a few questions I haven’t seen answered yet so I’m bumping them. </div><div class=""><br class=""></div><div class="">-Matthew</div><div class=""><br class=""><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?<br class=""><font color="#5856d6" class=""><br class=""></font>var [baseProp] x // no initializer, ok as long as base doesn't have init req?<br class="">var [initializerReqt] y // no initializer, error because of the initializer requirement?<br class=""></div></div></div></div></blockquote><div class=""><br class=""></div><div class="">Sorry, I thought I explained this. The default stored property that gets instantiated for a base property can be initialized out-of-line, so the inline initializer expression is optional, yes.</div></div></div></div></blockquote><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 class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class=""><font color="#5856d6" class=""><br class=""></font>Another thing that isn’t clear is what happens when a property with a behavior is set within the initializer of the containing type:<br class=""><font color="#5856d6" class=""><br class=""></font>struct S {<br class=""> var [observed] s: String<br class=""> init(s: String) {<br class=""> // What happens here? Is the behavior’s “set” accessor called? <br class=""> // This may not always be desirable, as in the case of “observed"<br class=""> self.s = s<br class=""> }<br class="">}<br class=""></div></div></div></div></blockquote><div class=""><br class=""></div><div class="">Just like today, assignments within the initializer would bypass the behavior and directly initialize the storage.</div></div></div></div></blockquote><div><br class=""></div><div>Thanks for clarifying.</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=""><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=""><font color="#5856d6" class=""><br class=""></font>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.<br class=""></div></div></div></div></blockquote><div class=""><br class=""></div><div class="">That's a possibility, but inserting initializer calls is a bit more heroic than what our current definite initialization implementation can do. That's not necessarily a showstopper, but it was a goal of the current design to avoid inserting accessor calls within inits at hard-to-predict places. (cc'ing ChrisL, to get his opinion on this as DI owner)</div></div></div></div></blockquote><div><br class=""></div><div>Makes sense. Getting the behavior I would like to see out of a `phase2Immutable` behavior would definitely require updates to the DI rules. I think the added safety makes it worth doing something in this area eventually, but it could be added later. I’m interested to hear what Chris thinks.</div><div><br class=""></div><div>-Matthew</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=""><br class=""></div><div class="">-Joe</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=""><font color="#5856d6" class=""><br class=""></font>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). <br class=""><font color="#5856d6" class=""><br class=""></font>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. <br class=""><font color="#5856d6" class=""><br class=""></font>The behavior might look like this:<br class=""><font color="#5856d6" class=""><br class=""></font>public var behavior phase2Immutable<Value>: Value {<br class=""> private var value: Value? = nil<br class=""><font color="#5856d6" class=""><br class=""></font> get {<br class=""> guard let value = value else {<br class=""> fatalError("property accessed before being initialized")<br class=""> }<br class=""> return value<br class=""> }<br class=""> <br class=""> init {<br class=""> value = initialValue<br class=""> }<br class="">}<br class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class=""></div></div>This would be a significant improvement over delayedImmutable in many use cases IMO.</div></div></div></div></blockquote></div><br class=""></div></div></blockquote></div><br class=""></body></html>