> On Oct 4, 2017, at 9:40 PM, Taylor Swift <kelvin1...@gmail.com> wrote: > > > - 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. > > 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.
Yep, something like that would definitely be possible by a sufficiently smart compiler, it is compatible with both approaches. -Chris
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
