<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 20:46 , Slava Pestov <<a href="mailto:spestov@apple.com" class="">spestov@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><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=""><blockquote type="cite" class=""><div class=""><br class="Apple-interchange-newline">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=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><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<span class="Apple-converted-space"> </span><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<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 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<span class="Apple-converted-space"> </span><i class="">all paths</i>.<br class=""></div></div></div></blockquote><div class=""><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></blockquote><div><br class=""></div><div>IIRC mandatory inlining runs after DI. I think Chris didn't want cases where the DI looked wrong but was correct because the called function happened to be inlined—there's no indication at the call site of this.</div><div><br class=""></div><div>We also wouldn't want the <a href="https://github.com/apple/swift/blob/master/docs/TransparentAttr.rst" class=""><i class="">other</i> semantics of transparent</a>: no debug info, and restrictions on what can be mentioned if it's marked public.</div><div><br class=""></div><div>Jordan</div></div></body></html>