/ go Public
cmd/compile: optimize recursive closure calls #59708
Issues related to the Go compiler and/or runtime.
Feedback is required from experts, contributors, and/or the community before a change can be made.
It is often convenient to define recursive functions local to some outer function, either because you don't want to pollute the package namespace with helper functions, or because the recursive function wants to close over locals of the outer function. Of course Go doesn't have recursive function literals so you have to fake it by using the var trick. The escape analysis is smart enough to avoid heap-allocating the closure in such cases, but unfortunately the actual recursive call is still dynamic.
Could the compiler be made smart enough to notice that the
visitvariable is assigned exactly once to a func literal, and thus it is safe to turn the whole thing into a letrec so that the call to visit becomes static?
The text was updated successfully, but these errors were encountered: