cc @randall77 , @dr2chase

This optimization is also known as devirtualization in C++ compilers.

How would this impact stack traces appearing after a panic that refer to rewritten funcs?

It's not obvious to me how this works with package-at-a-time compilation. For example, it would seem to require re-compiling package sort when a new type satisfying sort.Interface shows up.

This can be done semi-manually with an source code rewriter/specializer--which the sort package in fact has internally. :)

@josharian what about unexported funcs?

How often does that happen? This optimization would (I think) take pretty significant effort to implement. And if all the code is in the same package, then it could be specialized manually or with a source code generator, like in package sort.

How often does that happen?

One example that comes to mind is funcs that you want to test, so you make them take interfaces to help with the mocking. If you made it take an interface just for that, when compiling in non-test mode the interface type could be swapped with a single specific type.

I don't think you could specialize this manually, and I think this pattern is fairly well regarded.

I agree that this optimization would probably be far from trivial and most interface uses wouldn't benefit, though (unless inlining takes place?).

Forgot mentioning that the devirtualization may help escape analysis leaving more variables on stack. For instance, currently all the variables passed to interface functions are escaped because the compiler doesn't know all the function implementations which may be used in the program. With the devirtualization step the compiler may leave part of such variables on stack.

How would this impact stack traces appearing after a panic that refer to rewritten funcs?

This shouldn't change stack traces at all

It's not obvious to me how this works with package-at-a-time compilation. For example, it would seem to require re-compiling package sort when a new type satisfying sort.Interface shows up.

I don't know how the current compiler works, but here is a naive sketch how the devirtualization may be implemented:

• Step 1 - AST building. Each package is parsed into AST and the results are marshaled to cache files.
• Step 2 - Analysis. Scan each AST and fill the calls map[funcName]set[argTypes] for all the functions accepting at least one interface argument.
  • funcName is fully qualified function name: path/to/package.funcName
  • argTypes - a tuple of real argument types used in each call to the function.
• Step 3 - Rewriting. For each function that that has only a single element in the set[argTypes] rewrite its' AST by substituting interface args with real args from argTypes.
• Step 4 - Compilation. Compile each packages' AST.