<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 4 Oct 2017, at 07:11, 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=""><meta http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div class=""><br class=""><blockquote type="cite" class=""><div class="">On Oct 3, 2017, at 10:09 PM, Chris Lattner <<a href="mailto:clattner@nondot.org" class="">clattner@nondot.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="">On Oct 3, 2017, at 9:59 PM, Slava Pestov <<a href="mailto:spestov@apple.com" class="">spestov@apple.com</a>> wrote:<br class=""><div class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><blockquote type="cite" class=""><div class=""><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><blockquote type="cite" class=""><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><div class="">It wouldn't avoid the complexity, because we want the "non-ABI, always-emit-into-client" behavior for the standard library. For the soon-to-be-ABI-stable libraries where @inlinable even matters, such as the standard library and Apple SDK overlays, there's pretty much perfect overlap between things we want to inline and things we don't want to take up binary space and ABI surface in binaries, so the behavior Slava proposes seems like the right default. </div></div></div></blockquote><br class=""></div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">I disagree. The semantics being proposed perfectly overlap with the transitional plan for overlays (which matters for the next few years), but they are the wrong default for anything other than overlays and the wrong thing for long term API evolution over the next 20 years.</div></div></blockquote><div class=""><br class=""></div>Can you elaborate on this? If inlinable functions have public entry points, the version in the framework may or may not be called… because of SIL serialization and inlining. Since the existence of the public entry point doesn’t offer much of a guarantee, it seems desirable to not have the public entry point. For example if the inlinable function is not used elsewhere in the framework, we wouldn’t have to emit it at all. This might make the standard library smaller for instance.</div></div></div></blockquote><div class=""><br class=""></div><div class="">Sure, let me explain the same thing a different way: because the symbol is known to be present, clients are not *forced* to inline the body of the function if it is not profitable. They know that there is always a single canonical implementation of the function, so they aren’t forced to replicate it N times for N clients.</div><div class=""><br class=""></div><div class="">Remember also that there are times where the body of a symbol isn’t the thing that is useful. If you curry a method for example, you want its address. With the proposed inlining semantics, this forces a copy of the body to be emitted in every module that uses it, because you don’t have a canonical name for the thing.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class="">However I’m still waiting for Dave or Jordan to chime in with the original justification for the ‘always emit into client’ behavior. IIRC there was a resilience-related argument too, but I don’t remember what it is now.</div></div></div></blockquote><br class=""></div><div class="">The only argument I can imagine is the “If it gets inlined, you’re guaranteed to get the version of the symbol you build against”. The concern is that some instances are inlined and some are not, and if the inline and out of line versions diverge then you can have exciting problems.</div><div class=""><br class=""></div><div class="">My view on that is that you’ve already lost if you’d done this. If you mark a declaration as fragile (allowing it to be inlined) you’ve specifically guaranteed that you’re not going to be changing the observable semantics of the function. Introducing new performance optimizations is fine of course.</div></div></div></blockquote><br class=""></div><div class="">I understand your reasoning here, but note that in Jordan’s proposal, he’s adding two new keywords, exhaustive and nonexhaustive. If exhaustive becomes @fragile, does nonexhaustive still make sense?</div></div></div></blockquote><div><br class=""></div><div>I’ve already made this argument in the corresponding thread: I’m against <b class="">nonexhaustive</b> because it is the default behaviour (for the same reason we don’t have/need non-final). Therefore, I wouldn’t feel bad about seeing it go.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class="">Slava</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>