`@nameOf` built in function

[batiati]

Proposal

Introduce a new built-in function @nameOf that returns the name of any declaration (fields, functions, variables, consts, etc) as a comptime []const u8.

Motivation

Even with most of comptime strings being capable of raise compiler errors, strings are not easily trackable/refactorable when the underlying declaration changes. Many IDEs have some sort of feature allowing automated code-refactoring, which would be hard to use against strings.

Simple example

//Use @nameOf
var self = @fieldParentPtr(Self, @nameOf(allocator), allocator);
const NAME = @nameOf(NAME);

// instead of a string
var self = @fieldParentPtr(Self, "allocator", allocator);
const NAME = "NAME";

Drawbacks

As a built-in function, @nameOf must be capable to accept expressions that aren't valid in normal statements, for example:

// Allow to refer to a field without a instance of MyStruct
_ = std.meta.trait.hasField(@nameOf(MyStruct.name));

Similar behavior is observed in C#'s nameOf operator.

[Rocknest]

What does this mean?

// Allow to refer to a field without a instance of MyStruct
_ = std.meta.trait.hasField(@nameOf(MyStruct.name));

Do you want to refer to a field and only then check if it exists?

And most likely there is no easy way to make it work with generic types, so it would be useless for IDEs.

[batiati]

What does this mean?

const MyStruct = struct {
    name: []const u8,
};

fn somefunc() void {

    var myInstance = MyStruct { .name = "bob" };

    // Expected "name"
    _ = @nameOf(myInstance.name); 

    // Expected "name"
    // In normal statements you can't refer to a field this way, but it makes sense for @nameOf
    _ = @nameOf(MyStruct.name); 

}

And most likely there is no easy way to make it work with generic types, so it would be useless for IDEs.

  // Expected "items"
  _ = @nameOf(std.ArrayList(i32).items);

As I said, most of comptime string usage will raise compiler errors, like @field(myStruct, "there_is_no_such_field"), but I feel very uncomfortable spreading strings constants related to names already declared in the code.

[Vexu]

I think this has been previously rejected but I can't find the issue (possibly deleted?).

[Rocknest]

@batiati

// Expected "items"
_ = @nameOf(std.ArrayList(i32).items);

Consider this:

fn (comptime T: type) void {
  _ = @nameOf(T.items);
}

There is no easy way for IDE to help with refactoring here (multi-build analysis required)

[czrptr]

@batiati

Could you give another example where @nameOf would help with refactoring? In the example you've given, changing the name of NAME would require as much effort with @nameOf as with a hardcoded string since you would have to chenge the argument of @nameOf (this also applies with struct fields).

const NAME = "NAME";
//    ~~~~    ~~~~

const NAME = @nameOf(NAME);
//    ~~~~           ~~~~

I've known about C#'s nameOf operator since it was introduced but have never found a use for it. I'm not against this feature, I just don't see it providing a cleaner solution to the problems you've mentioned.

Also the drawback you mention is significant IMO since Type.field is not a valid expression (Type acting like a namespace and field being tied to an instance). Making this legal would introduce an inconsistency in the language (making it more complicated) and this feature doesn't look powerful enough to me to warrant taking on this complexity.

[ikskuh]

A @nameOf builtin has the signficiant benefit of failing to compile instead of just doing the wrong thing:

Consider this refactoring:

var foo = "Hello";

try writer.print("  \"{s}\": \"{s}\"\n", .{ "foo", foo }); // without
try writer.print("  \"{s}\": \"{s}\"\n", .{ @nameOf(foo), foo }); // with

=> (ah, let me just quickly fix all compile errors)

var bar = "Hello";
try writer.print("  \"{s}\": \"{s}\"\n", .{ "foo", bar }); // without: probably wrong serialization
try writer.print("  \"{s}\": \"{s}\"\n", .{ @nameOf(foo), bar }); // with: error: use of undeclared identifier 'foo'

[czrptr]

I see. @nameOf would indeed be very useful in the context of a serialization library for example. Now I see it's usefulness.

[batiati]

Hi @czrptr

Could you give another example where @nameof would help with refactoring? In the example you've given, changing the name of NAME would require as much effort with @nameof as with a hardcoded string since you would have to chenge the argument of @nameof (this also applies with struct fields).

I have a similar case as stated above by @MasterQ32's serialization example. I'm working on a data-binding engine for a MVC-like UI, and I found myself repeating the same symbol's names many times as strings ... and I missed some IDE support too, like autocompletion.

Also the drawback you mention is significant IMO since Type.field is not a valid expression (Type acting like a namespace and field being tied to an instance). Making this legal would introduce an inconsistency in the language (making it more complicated) and this feature doesn't look powerful enough to me to warrant taking on this complexity.

Sure, I agree.
I just pointed out that C# behaves in that manner, allowing nameof/typeof to do things not allowed by the regular grammar, like var name = nameof(Type.InstanceField), var name = nameof(MethodNameWithoutArgs) and var type = typeof(TemplatedClassWithoutTemplate<>);.

I'm not a PL person, so I have no idea how hard is to make this work, but maybe @nameof could return any token as a string, without further syntactic analysis.

[Cons-Cat]

This is something I've been wanting before in other languages. To my knowledge, C preprocessor macros cannot express surrounding an argument with "". C++ allows you to get a name-mangled string from a symbol, but de-mangling it is implementation defined and that string cannot be constexpr. Implementing this proposal would be very nice for Zig, in my humble opinion.

[ikskuh]

@Cons-Cat just for clarification:

#define NAMEOF(x) #x

should do the job for both C and C++ based on the preprocessor