> On Oct 3, 2017, at 9:56 PM, Chris Lattner <clatt...@nondot.org> wrote: > > >> On Oct 3, 2017, at 9:50 AM, Joe Groff <jgr...@apple.com> wrote: >> >> >> >>>> On Oct 2, 2017, at 10:58 PM, Chris Lattner via swift-evolution >>>> <swift-evolution@swift.org> wrote: >>>> >>>> We have discussed adding a "versioned @inlinable" variant that preserves >>>> the public entry point for older clients, while making the declaration >>>> inlinable for newer clients. This will likely be a separate proposal and >>>> discussion. >>>> >>> 5) It eliminates this complexity. >> >> 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.
I disagree with this. 'inline' functions in C and C++ have to be backed by a symbol in the binary in order to guarantee function pointer identity, but we don't have that constraint. Without that constraint, there's almost no way that having a fallback definition in the binary is better: - It becomes an ABI compatibility liability that has to be preserved forever. - It increases binary size for a function that's rarely used, and which is often much larger as an outlined generic function than the simple operation that can be inlined into client code. Inlining makes the most sense when the inlined operation is smaller than a function call, so in many cases the net dylib + executable size would increase. - It increases the uncertainty of the behavior client code sees. If an inlinable function must always be emitted in the client, then client code *always* gets the current definition. If an inlinable function calls into the dylib when the compiler chooses not to inline it, then you may get the current definition, or you may get an older definition from any published version of the dylib. Ideally these all behave the same if the function is inlinable, but quirks are going to be inevitable. -Joe > > -Chris > >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
