Macro that expands into string holding function name (or module path, etc)

[pnkfelix]

View all comments

RFC #466 was closed back in the days before we had a protocol for opening up follow-up issues to use to gather links to related discussion.

The idea is that we already have some macros (file! and line!) that are useful for reporting source code context, and it might be nice to expand that collection with macros that include other information, such as the current function name, which I believe was the suggestion of the function! macro that was at one point described in RFC #466 (whose draft contents have now been lost, apparently).

Here is my attempt to retrieve the Motivation from that original draft text. (I don't think we need the detailed design in the description of an issue like this.)

Motivation

For error reporting cases we already have file!, line!, col! and module_path!
but there is no way yet to figure out in which function an error was reported. Python's
tracebacks are well received and for many people the function name information is much
more important than the line number.

• An alternative (or complement) would be to have a module_path! macro that expands into a string representing the path to the current module; such a macro would be usable outside of fn definitions, e.g. in static items.

[oli-obk]

there's an open RFC for the function name: #1719

[NeoLegends]

C# has a nice implementation of this: They have the nameof()-operator, which returns the name of the type, method or variable you put into it. https://msdn.microsoft.com/de-de/library/dn986596.aspx

[mqudsi]

Not really. C#'s nameof is "dumb" and returns literally whatever you type into it, only as a string. With generics, nameof(T) returns T and with a function, you'd have to type the function name each time (i.e. log!("Entering {}", nameof(this_function_name)), whereas with a proper __function__ macro, that can be turned into a copy-and-paste friendly log!("Entering {}", fn_name!()) or similar.

[da-x]

Hi all,

I've implemented this feature over current Rust beta in:

https://github.com/da-x/rust/tree/function-macro

I have not included type parameters in the output string because it's not very useful for me. But I did include the nesting, though (a::b..).

This is my first time hacking on Rust's compiler, so bear with me that it may be ugly/inefficient, etc.

@da-x quick question: #1719 (comment)

EDIT: sounds like line numbers would be a good way to differentiate two same-named inner functions that are at the same nest-level.

EDIT2: I've decided to not post the following as a new post, and just discard it; but on second thought, I figured I might as well include it here(hidden by a `details` tag, ie. click me to open) - it's a reply attempt to the next comment by da-x

anyone needing uniqueness should tuple the result of function!() with line!() and friends.

It's worth noting that such use of line!() would return the line number of the call, not the line number of the function definition, which is fine; but then maybe function!() should also not try to act like a function_path!(), perhaps?(although, you could argue, that the reason it does this is because for most use cases it's still a good differentiator and somewhat unlikely to hit cases like in my example below)

Taking example from your implementation,

function_path!() would return

    test
    main
    main::inner
    main::inner::inner_a
    main::inner2
    main::inner2::inner_b

function_name!() would return:

    test
    main
    inner
    inner_a
    inner2
    inner_b

The following example( playground ) gives an idea why function_path!() could be just as useless as function_name!(), line!() however saves the day:

fn main() {
    {
        fn inner() {
            println!("inner/{}", line!());
            fn inner_a() {
                println!("inner::inner_a/{}", line!());
            }
            inner_a();
        }
        inner();
    }
    fn inner() {
        println!("inner/{}", line!());
        fn inner_a() {
            println!("inner::inner_a/{}", line!());
        }
        inner_a();
    }

    inner();
}
//output:
inner/4
inner::inner_a/6
inner/13
inner::inner_a/15

[da-x]

@xftroxgpx another case to consider are two calls to function!() within in the exact same function - therefore I think that no assumption of uniqueness should be made on the result of multiple function!() invocations within a crate. So my opinion is that anyone needing uniqueness should tuple the result of function!() with line!() and friends.

[LEXUGE]

So, What's the status of it?

[da-x]

Now that I am actually using my implementation in the logging system I am writing, I fixed some bugs there. Updated my branch (also rebased ontop 1.25.0). Before, the names from methods functions, default implementation of trait methods, and the name of the struct for which the method is implemented, were all missing.

[da-x]

Hi all,

Although the RFC is not fully formed, I submitted an implementation as a pull request so we can have a working reference implementation that may assist in promoting the discussion and maybe reach some conclusions how to move this forward.