<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 6:48 PM, Jordan Rose 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=""><div class=""><br class=""></div><div class=""><div class=""><blockquote type="cite" class="">3. Partial initializers and initialization methods may include an access control modifier specifying their visibility.</blockquote><br class=""></div></div><div class="">I'm a little concerned about exposing these things publicly: there's no point if the struct or class has non-public fields (because new non-delegating initializers can't initialize the non-public fields), and by default every struct and class is allowed to <i class="">add</i> non-public fields in new versions of a library. (See the LibraryEvolution.rst doc for more info.) I can kind of see making these private vs. internal, but that has other issues (see below).</div><div class=""><br class=""></div><div class="">Even in the case where all fields are public and the struct promises not to change any fields, you'd <i class="">also</i> have to promise that the partial initializer never changes which properties it's initializing; that's now part of the binary interface of the file. That's unusual for something that behaves like a function; usually the body is not part of the ABI.</div><div class=""><br class=""></div><div class="">I'd much rather just ban 'public' and never have partial inits be part of a library's public interface. Public initializer methods would be presented as plain methods, with no hint of their initializer origins.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><blockquote type="cite" class="">9. The compiler keeps track of the properties initialized by a partial initializer or initialization method and uses that knowledge when enforcing initialization rules in phase one in the calling initializer.</blockquote><div class=""><br class=""></div>If a struct partial initializer is defined in another file, this would require reading the body of the initializer to determine what variables it initializes. We currently don't type-check any bodies outside of the primary source file when doing a normal, multi-process compilation.</div><div class=""><br class=""></div><div class="">You're missing a DI condition here in the sub-bullets, which is that the partial initializer must initialize its subset of stored properties on <i class="">all paths</i>.<br class=""></div></div></div></blockquote><div><br class=""></div>I believe you can already factor out common code in initializers by defining @_transparent functions. Would it be more worthwhile to improve @_transparent by fixing the known limitations instead?</div><div><br class=""></div><div><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="">What happens when you call an init method from phase 2 of initialization? Is that just illegal?</div></div></div></blockquote><div><br class=""></div>Note that @_transparent functions can be called in phase 1 or phase 2 — DI figures out which sets are initialization stores, and which ones release the old value.</div><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="">I'm ultimately <i class="">still</i> not convinced that this is the right way to reduce initializer boilerplate (phase 1 duplication between initializers, or shared code between initializers and methods). It again adds complexity to the language, and that added complexity may not be worth the payoff. I'm thinking about someone coming across the construct for the first time: would they understand what it was doing? Would they understand the error messages they would get?</div><div class=""><br class=""></div><div class="">(Specifically on that note: "init func" is probably okay because it's a special kind of func, but I think I would personally prefer to keep the 'partial' keyword for partial inits, even though it's technically unnecessary.)</div><div class=""><br class=""></div><div class="">Sorry for the somewhat scattered thoughts. Hope it's helpful.</div><div class="">Jordan</div><div class=""><br class=""></div><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Jan 14, 2016, at 20:08, 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=ZEz4qHYnXhPr3bBPu-2FxP4tN3HfWKL-2FtJpqkQ0gkOVSBA1RWShn3xA6rbNnnGhqRjzSX6-2BNfSVBW0qdMNmA-2FD-2Fgbv4NIKoEvXcUesrisuHWNoyLemNRmIRr3mA5zBklkY3-2BR6UWSgK1brFciZQ-2B4fyYXEIsx3-2FRtsVZ4zFwoCYrcRqi-2BeUk62ZnGwyj3lDo5tRVcemwwqvA8tCHG-2F9ee7Zi-2FwBC8j6N7F626lsFgATmc-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>_______________________________________________<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>