proposal: add compiling time constants like __FUNC__, __LINE__, __FILE__ of cpp in Golang

[NetWilliam]

Considering a trace log with line no and func name, we would be able to locate the problem more quickly.

[AlexRouSg]

Like this?
https://golang.org/pkg/runtime/#Caller

func Caller(skip int) (pc uintptr, file string, line int, ok bool)

Caller reports file and line number information about function invocations on the calling goroutine's stack. The argument skip is the number of stack frames to ascend, with 0 identifying the caller of Caller. (For historical reasons the meaning of skip differs between Caller and Callers.) The return values report the program counter, file name, and line number within the file of the corresponding call. The boolean ok is false if it was not possible to recover the information.

[NetWilliam]

yes, but those are constant which are already known at the compiling time. It's better to express them as some constant rather than to evaluate them at the runtime for the sake of simplicity. @AlexRouSg

[agnivade]

Note that we already have constants in the log package which does this - https://golang.org/pkg/log/#pkg-constants.

Or are you saying you want more flexibility in the constants ? Like you want to print only line, or only filename ? In that case, I would request you to use the runtime package directly. Or create a separate package. The bar to include more API in standard library is pretty high.

In any case, this proposal needs more information for what precisely do you want, and where do you want those constants to be.

[FMNSSun]

Preferably in my opinion __FILE__ and __LINE__ would be tokens/lexems that get turned into string literals during tokenization/lexing so as far as the the whole backend part is concerned these constants do not even exist. Though that may require a change to the language spec indeed. Mapping them as constants later on in the process is probably more of an API change than a language spec change.

[cznic]

FTR, IINM __FUNC__ is actually spelled __func__ in the C99 standard.

[mark-rushakoff]

Is runtime.Caller(0) currently an actual call to the runtime, or does it / could it get effectively optimized into the literal file and line?

[NetWilliam]

My bad, I haven't noticed that log and glog have a SetFlags function to control the output content of logs.

I was thinking in a cpp way, which brought me to an idea that I could print __FILE__ __LINE__ and the goroutine ID in the logs to help me to trace the bugs. Now since you've set a constant in the logging lib to output its file name and line no, what about adding a new constant to output the goroutine ID in the logs?

I have noticed that there are some hacky ways to get the goroutine ID which don't appeal to me much cause of their complexities. And one big thing that really bothers developers much would be having no enough clear logs to debug, especially in a high concurrency situation as in Golang @agnivade

[agnivade]

So it seems you have now changed the proposal to trying to get a goroutine ID.

Please see this - https://golang.org/doc/faq#no_goroutine_id.

If you still believe you need a goroutine ID, I would request you to open a new proposal with the required details that outshine the reasoning in the faq article. Thank you.