<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 15, 2016, at 10:12 PM, David Owens II <<a href="mailto:david@owensd.io" class="">david@owensd.io</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="">I like the updates. I think the distinction between partial inits and init functions is extremely subtle. The only difference is that partial init can set `let` members, correct?</div></div></blockquote><div><br class=""></div><div>Hi David, glad you like the changes. </div><div><br class=""></div><div>Yes, that is the only difference, aside from the declaration syntax. It would be better if we didn’t need two separate forms but either one would sacrifice desirable functionality. </div><div><br class=""></div><div>Giving up the ability to initialize a `let` is unacceptable IMO. Giving up the ability to share code that initializes `var` properties with post-initialization callers is also undesirable. </div><div><br class=""></div><div>I considered having only once concept and allowing it to be called post-initialization if it only initializes `var` properties but I don’t like that approach. The compiler wouldn’t be able to check intent at the site of declaration (i.e. an init func that attempts to assign to a `let`) and it wouldn’t be clear to users which partial initializers could be called post-initialization and which cannot. </div><div><br class=""></div><div>That leaves us with the need for two very similar concepts. The only reasonable alternative seems to be dropping `init func`. I would do that it if it became a hurdle to accepting the proposal, but I think it will be a common use case and is worth including.</div><div><br class=""></div><div>Do you have any further thoughts? Do you agree with the decision I made here?</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">The only feedback I really have is that this makes the initialization rules even more complicated. I don't know how to address that though. =)</div></div></blockquote><div><br class=""></div><div>Agree, the rules are essential complexity if we want safe initialization. </div><div><br class=""></div><div>I think the small incremental increase in complexity is a worthwhile price to pay for the ability to factor initialization code. This is especially true if we’re going to add stored properties in extensions. I wouldn’t want to see a situation where we could have partial initializers, but only when we move some properties into an extension.</div><div><br class=""></div><div>I hope you agree.</div><div><br class=""></div><div>-Matthew</div><br class=""><blockquote type="cite" 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="">-David</div><div class=""><br class=""></div><div class=""><div class=""><div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Jan 14, 2016, at 8:08 PM, Matthew Johnson 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=""><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="">I have completed the second draft of my partial initializers proposal (the first really complete draft). <div class=""><div class=""><br class=""></div><div class="">This proposal also includes some discussion of memberwise initialization at John McCall’s request. If anyone would like to continue discussing that topic informally I will be happy to do so, however any such discussion should happen on one of the existing memberwise initialization threads or on a new thread related to that topic. Please do not let that section of the document be a distraction from the partial initializer proposal itself.</div><div class=""><div class=""><br class=""></div><div class="">The new draft can be found here:</div><div class=""><br class=""></div><div class=""><a href="https://github.com/anandabits/swift-evolution/blob/partial-initializers/proposals/NNNN-partial-initializers.md" class="">https://github.com/anandabits/swift-evolution/blob/partial-initializers/proposals/NNNN-partial-initializers.md</a></div></div><div class=""><br class=""></div><div class="">I really appreciate any feedback you have!</div><div class=""><br class=""></div><div class="">-Matthew</div></div>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=nE9rxSXA5G4kxsTVkgv43pXkLx-2B36P-2BPNJufHeY0dge1blMm6wJGoUM10n7uk96yci47bdSO9NZq2aGVE5ZP4kRyyBX9zwV4VZ0k-2FAfKcCm2J93zCgU3A4YswCB60e1OQmOzbLdezXFjEt5KUhkNBQ0NRQHAaxOEUpZUVwQb0H9BbtNRLp6aykeCIsKssbkRsyUFJQa8LOwt5ul7AOFHUg-3D-3D" alt="" width="1" height="1" border="0" style="height:1px !important;width:1px !important;border-width:0 !important;margin-top:0 !important;margin-bottom:0 !important;margin-right:0 !important;margin-left:0 !important;padding-top:0 !important;padding-bottom:0 !important;padding-right:0 !important;padding-left:0 !important;" class="">
</div>
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class=""></div></div></div></div></blockquote></div><br class=""></body></html>