<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 21, 2016, at 9:13 PM, Chris Lattner 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=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Jan 20, 2016, at 8:51 PM, Slava Pestov 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=""><span 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; float: none; display: inline !important;" class="">Adding more details…</span><div 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;"><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Jan 20, 2016, at 8:46 PM, Slava Pestov 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=""><div 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=""><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=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><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<span class="Apple-converted-space"> </span><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></div></blockquote></div></div></blockquote><div class=""><br class=""></div>If we just go with @_transparent functions for partial initialization, there are no new rules to add regarding ABI resilience. :-)</div></div></div></blockquote><br class=""></div><div class="">Ignoring the fact that @_transparent isn’t a user feature, I don’t see how this helps. Mandatory inlining of @_transparent happens after DI runs.</div></div></div></blockquote><br class=""></div><div>Sorry, I didn’t see that Jordan brought this up down-thread: He’s exactly right. We don’t *want* mandatory inlining to run before DI (it used to, and it was a mess). Doing that just makes the DI model more complex and less predictable for users.</div><div><br class=""></div><div>I’m not sold on the notion of partial initializers in the first place, but if we were to go down this path, the approach of nailing down the exact initialization behavior and requirements of the partial initializer - and making it part of its explicitly declared interface - is the right way to go.</div><div><br class=""></div><div>-Chris</div><br class=""></body></html>