> On Oct 3, 2017, at 10:09 PM, Chris Lattner <clatt...@nondot.org> wrote: > > On Oct 3, 2017, at 9:59 PM, Slava Pestov <spes...@apple.com > <mailto:spes...@apple.com>> 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. > > 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. > > 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. > >> 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 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. > > 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.
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? Slava
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
