<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 21:10 , Slava Pestov <<a href="mailto:spestov@apple.com" class="">spestov@apple.com</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:55 PM, Jordan Rose <<a href="mailto:jordan_rose@apple.com" class="">jordan_rose@apple.com</a>> wrote:</div><div class=""></div></blockquote><br class=""><blockquote type="cite" class=""><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="">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></blockquote><div class=""><br class=""></div><div class="">I don’t think that’s a huge problem though. When we emit a diagnostic about an uninitialized value or use, we could also emit a series of ‘inlined from here’ notes.</div></div></div></div></blockquote><div><br class=""></div><div>I think it's the other way around: when everything is <i class="">correct,</i> a new reader will look at the code and say "wait, why are you allowed to pass this inout here?" That applies less to partial initializers, though, which <i class="">do</i> have some syntax called out. We'd have to check with Chris to be sure, though, since it was a deliberate change at some point in the project's life.</div><div><br class=""></div><div>(It's also possible there's a pass ordering problem where we use DI to determine what can be promoted to the stack, or something like that. I'm not too familiar with the mandatory passes.)</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=""><div class=""><br class=""></div><blockquote type="cite" class=""><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=""><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="">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,</div></div></blockquote><div class=""><br class=""></div>That sounds unfortunate. Why is debug info with transparent functions any more of an issue than debug info for stuff inlined by the optimizer passes? I’m assuming we emit debug info for the latter.</div></div></div></blockquote><div><br class=""></div><div>No, you've got it backwards. This is a <i class="">feature</i> of transparent. Nobody wants to step into +.</div><div><br class=""></div><div>Now, we could break that feature out into a separate attribute, but then there's nothing "transparent" anymore. It's just "inline very early while we still have source locations to do diagnostics".</div><div><br class=""></div><div>Obviously, forced inlining can also hurt code size.</div><div><br class=""></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=""><blockquote type="cite" class=""><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=""> and restrictions on what can be mentioned if it's marked public.</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=""><br class=""></div></div></blockquote><div class=""><br class=""></div>Arguably, public partial inits only make sense for @_fixed_layout structs anyway :-)</div></div></div></blockquote></div><br class=""><div class="">But it affects initializer methods, which are just normal methods otherwise.</div><div class=""><br class=""></div><div class="">Jordan</div></body></html>