<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 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=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><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=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div 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></div></div></blockquote><br class=""></div><div>Swift’s semantics have a big (but largely invisible/unknown to developers) divide between initialization and reassignment. &nbsp;I agree that it makes sense to expose this different out of a behavior because they may want to do something interesting.</div><div><br class=""></div><div>That said, the divide shouldn’t be “assigned in an containing initializer” vs “assigned to somewhere else”. You should be able to have a behavior on a local variable for example.</div><div><br class=""></div><div>-Chris</div></body></html>