On Wed, Oct 4, 2017 at 11:44 AM, Joe Groff via swift-evolution < swift-evolution@swift.org> wrote:
> > > 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 > > i’m just tryna follow along here && this is probably a dumb question, but is it possible for a generic function to be emitted as a set of specialized functions into the client, but not inlined everywhere? It can be the case where a large generic function gets slowed down by the large number of generic operations inside it but it doesn’t make sense for it to be inlined completely.
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
