[weberc2]

I don't think anyone is pretending that Go is a decades-old language. What is the standard term for this kind of inlining which would distinguish it from the inlining already present in the compiler?

[pcwalton]

> What is the standard term for this kind of inlining which would distinguish it from the inlining already present in the compiler?

There isn't a standard term, because virtually all inliners always did what Go is now doing. It's pretty basic functionality.

[dilap]

Really? I feel like every C++ compiler I've used has given very unreliable stacktraces with optimizations enabled.

[jstarks]

Do most compilers preserve enough metadata to report accurate stacks?

[weberc2]

So they're not avoiding a standard term to be misleading; there simply isn't a standard term to use. Thank you for clarifying.

[Rusky]

The point is "inlining" already refers to this kind of inlining. The already-present form is more limited than the typical use of the term.

[sythe2o0]

Then what word would you have used in this presentation, given no established word existed?

[peteretep]

"Fixing Go's inlining"

[solidsnack9000]

"Go inlining improvements..." and then "Conventionally, inlining includes ... but Go has been limited to ... until recently. With ... Go now supports inlining in a broader array of circumstances."

[overcyn]

"Conventionally inclining includes ...?"

What does it include? You've conveniently managed to skip over the crucial part with ellipses. Calls in the middle of stacks perhaps?

You people have too much time on your hands to go and pick at the wording people use in their presentations.

[solidsnack9000]

> You people have too much time on your hands to go and pick at the wording people use in their presentations.

What kind of argument is that?

[overcyn]

I'm saying that this is an incredibly inane, nitpicky, superficial conversation that has nothing to do with the technical content of the presentation.