<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 4:08 PM, Joe Groff via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; 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:48 AM, Matthew Johnson &lt;<a href="mailto:musical.matthew@mac.com" class="">musical.matthew@mac.com</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><blockquote type="cite" class="" 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;"><div class=""><br class="Apple-interchange-newline">On Jan 20, 2016, at 11:39 AM, Joe Groff &lt;<a href="mailto:jgroff@apple.com" class="">jgroff@apple.com</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Jan 20, 2016, at 9:31 AM, Matthew Johnson &lt;<a href="mailto:musical.matthew@mac.com" class="">musical.matthew@mac.com</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">Joe,&nbsp;<div class=""><br class=""></div><div class="">I’m wondering if you missed my comments. &nbsp;I had a few questions I haven’t seen answered yet so I’m bumping them.&nbsp;</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<span class="Apple-converted-space">&nbsp;</span><b class="">required</b>&nbsp;but is a little bit less clear about when it may be left off. &nbsp;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="" 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;"><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class=""><br class=""><blockquote type="cite" class=""><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><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="">&nbsp; var [observed] s: String<br class="">&nbsp; init(s: String) {<br class="">&nbsp; &nbsp; // What happens here? &nbsp;Is the behavior’s “set” accessor called? &nbsp;<br class="">&nbsp; &nbsp; // This may not always be desirable, as in the case of “observed"<br class="">&nbsp; &nbsp; self.s = s<br class="">&nbsp; }<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 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="">Thanks for clarifying.</div><br class="" 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;"><blockquote type="cite" class="" 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;"><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class=""><br class=""><blockquote type="cite" class=""><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><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). &nbsp;This would clarify what happens during initialization of the containing type and allow for different init and set code paths when necessary. &nbsp; It would be distinguished from the behavior initializer by the lack of parens. &nbsp;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 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="">Makes sense. &nbsp;Getting the behavior I would like to see out of a `phase2Immutable` behavior would definitely require updates to the DI rules. &nbsp;I think the added safety makes it worth doing something in this area eventually, but it could be added later. &nbsp;I’m interested to hear what Chris thinks.</div></div></blockquote><div class=""><br class=""></div>I think it's important that delayed initialization also accommodate initialization *after* init() returns. There are many cases where full initialization depends on a process outside of init's control, especially in Cocoa with objects and outlets set up from nib files.</div></div></div></blockquote><div><br class=""></div><div>Sure, that’s an important use case. &nbsp;But I think the use case where you only need to delay initialization until phase 2 due to a back reference, etc is also important and the added safety of guaranteeing initialization *must* happen during phase 2 is highly desirable.</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=""><br class=""></div><div class="">-Joe</div></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>