<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="">When someone vendors or statically links a library, they <i class="">know</i> what they are getting into. I mean, sometimes people do silly things, but they <i class="">should</i> know.<div class=""><br class=""></div><div class="">Whereas "inlining across dynamically linked libraries" is a novel Swiftism (Or it may be a Rustism as well but in any case) nobody expects it. They will assume that replacing the dynamic library actually replaces the dynamic library's code, because that is the social contract for dynamic linkage.</div><div class=""><br class=""></div><div class="">More broadly, I see inlining dynamic libraries as a "nice to have", but dynamic linkage that actually works as "critical". This proposal inverts that value system, telling me that I <i class="">will</i> get inlined performance, and I <i class="">might</i> get a correctly linked program. That seems backwards.</div><div class=""><br class=""></div><div class="">Or stated another way: if I can't relink my program afterwards, why am I using dynamic linkage? I should statically link everything.</div><div class=""><br class=""></div><div class="">Let me advance an independent argument why I think this is the wrong behavior: LGPL compliance. Eliding LGPLv3 §4)d)1:</div><div class=""><br class=""></div><div class=""><blockquote type="cite" class="">You may convey a Combined Work... if you... Use a suitable shared library mechanism for linking with the Library. A suitable mechanism is one that (a) uses at run time a copy of the Library already present on the user's computer system, and (b) will operate properly with a modified version of the Library that is interface-compatible with the Linked Version.</blockquote></div><div class=""><br class=""></div><div class="">and §4)e:</div><div class=""><br class=""></div><div class=""><blockquote type="cite" class="">Provide Installation Information... to the extent that such information is necessary to install and execute a modified version of the Combined Work produced by recombining or relinking the Application with a modified version of the Linked Version. </blockquote></div><div class=""><br class=""></div><div class="">I suspect that linking an LGPLed library under this proposals' semantics may be a lawsuit foot-gun.</div><div class=""><br class=""></div><div class="">...inb4 "don't use the LGPL", but I think this (and the security problem) generalize to a very broad class of issues. Dynamic linkage has a certain "social contract" since time immemorial. Breaking this contract has consequences that I am not sure we have thought through entirely.</div><div class=""><br class=""></div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Feb 10, 2016, at 9:46 PM, Joe Groff <<a href="mailto:jgroff@apple.com" class="">jgroff@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">I don't think there's a silver bullet here. Even if the implementation is inside the binary, you'll still have clients with vendored or statically linked copies of old versions of your library embedded in their distributions. Clients always have to share in the responsibility for maintaining their security.<br class=""><br class="">-Joe<br class=""><br class=""><blockquote type="cite" class="">On Feb 10, 2016, at 6:08 PM, Drew Crawford via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class=""><blockquote type="cite" class="">I think the solution is that you shouldn't mark security-critical code as being eligible for inlining. Anything else is just not going to be workable.<br class=""></blockquote><br class="">There is no such thing as "I solemnly swear this function doesn't have a security bug, and if it does, we'll never patch it."<br class=""><br class="">If we have to choose between security and inlining, let's not allow inlining across versioned APIs.<br class="">_______________________________________________<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=""></blockquote><br class=""></div></div></blockquote></div><br class=""></div></body></html>