> On 4 Oct 2017, at 07:11, Slava Pestov via swift-evolution > <swift-evolution@swift.org> wrote: > > > >> On Oct 3, 2017, at 10:09 PM, Chris Lattner <clatt...@nondot.org >> <mailto: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?
I’ve already made this argument in the corresponding thread: I’m against nonexhaustive 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. > Slava > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
