Add `line()` and `function()` @GDScript global functions to get the line/function the function was placed at

[FireCatMagic]

Describe the project you are working on

All projects

Describe the problem or limitation you are having in your project

no way to obtain current line or function in GDScript while you can in C++

Describe the feature / enhancement and how it helps to overcome the problem or limitation

It would essentially be the same as the __LINE__ and __FUNCTION__ macros in C++, except they'd be built in global functions only accessible in GDScript This functionality seems to already be in there somewhat with print_debug

line() would return an int of the current line of the script function() would either return a callable of the current function, which would give it more usage than just debug printing, or a String containing the current function name

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

GDScript is core

If this enhancement will not be used often, can it be worked around with a few lines of script?

GDScript is core

Is there a reason why this should be core and not an add-on in the asset library?

GDScript is core

[sockeye-d]

I think there should be a method to get the script path as well. It might be hard to get to work in release builds though

[dalexeev]

Note that since GDScript doesn't have macros, this feature would be limited in its use (see https://github.com/godotengine/godot-proposals/issues/837#issuecomment-629325298). You could use it to print errors, but there are already functions that print the source location, such as push_error(), push_warning(), print_debug(). Also, if we were to introduce this feature, I don't see any reason why they should be functions instead of "magic" constants like in other languages (__FILE__, __LINE__, __FUNC__).

I think there should be a method to get the script path as well.

Note that you can already do this:

print(get_script().resource_path)

[FireCatMagic]

I don't see any reason why they should be functions instead of "magic" constants like in other languages (__FILE__, __LINE__, __FUNC__).

I think they should be functions because that's how other things work. Mainly thinking of get_remote_sender_id of MultiplayerAPI which only works inside RPC functions so it has to have extra functionality like that.

For my use case, the push_X or print_debug functions aren't enough when I want to make my own console since to my knowledge I can't extract the String from it, as currently its impossible to obtain the line number or function as a String.

For these functions to work there already seems to be logic in the engine that works for the print_debug etc functions.

I didn't include a file() function specifically because of get_script()

[dalexeev]

I think they should be functions because that's how other things work. Mainly thinking of get_remote_sender_id of MultiplayerAPI which only works inside RPC functions so it has to have extra functionality like that.

If this is implemented, it will likely be as a language feature, unlike get_remote_sender_id(). The values ​​will be known at compile time, rather than being evaluated at runtime via stack unwinding. Yes, we could make this function-like keywords like assert() and preload(), but that doesn't make sense since the arguments are not needed. That would require an additional note X is a keyword, not a function. So you cannot access it as a Callable.