Change https://golang.org/cl/335469 mentions this issue: log: add Lshortfunc and Llongfunc flags

Hi, I've add a PoC CL above.

/cc @robpike

That's adding an expensive step, an interesting contrast to the other recent logging proposal that tries to make it cheaper.

From an API perspective, you'll soon want more than two new flags to control which function is logged: the one that called log.Print, its parent, and so on. The flags will expand if this is adopted.

The log package is a fine basic tool, which is what it was meant to do. There are many external logging packages that provide much richer functionality, and that's the right place to look for this feature.

Also, note that it's easy to just put the function name in the call itself, either by hand or automation. The log package itself doing would only add ease, not ability.

This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— rsc for the proposal review group

I am not sure this is worthwhile, since the function name can get quite long, methods have awkward names, closures have no real name, and so on. The file:line is far more precise and useful.

That said, it's not expensive, nor does it add more API complexity than the extra flag bit. Presumably you'd want file/line/function to always be in sync, so there wouldn't be an extra 'which function' knob beyond the existing one that controls file/line (the depth argument to Output). Today the code does:

	_, file, line, ok = runtime.Caller(calldepth)

It would have to use the ignored result (pc) and call runtime.FuncForPC to get the name. The file/line lookup was much more expensive than resolving the pc to the function name.

So it's not expensive. It just may not be terribly useful.

Based on the discussion above, this proposal seems like a likely decline.
— rsc for the proposal review group

No change in consensus, so declined.
— rsc for the proposal review group