> On Oct 4, 2017, at 9:15 PM, Chris Lattner <[email protected]> wrote: > > >> On Oct 4, 2017, at 9:36 AM, Joe Groff <[email protected] >> <mailto:[email protected]>> wrote: >> >>>>> 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. >>>> >>>> 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. >>> >>> 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. >>> >>> 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. >> >> The suggestion to have this semantics was originally my fault, I believe, >> and it arose from the observation that if we have 'inlinable' backed by a >> symbol in the binary, then we'd also want the 'must be emitted by client' >> attribute. I think 'must be emitted by client' is going to almost always be >> preferable for an inlinable function, though, so it's better to have the >> single attribute with this behavior, only constrained by backward deployment. > > What is the use case of “must be emitted by client” attribute? If I imagine > that the Swift 5 standard library is shipped in the OS, I can see cases where > deprecated/legacy shims for Swift3/4 compatibility would be emitted into the > client but not shipped in the OS. Those seem relatively obscure though.
You could just as easily pose the opposite question—what's the use case for a symbol in the dylib when the definition is visible to clients? Evaluating the tradeoffs, we feel like it's better not to unless backward compatibility demands it. -Joe
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
