Proposal: Make ambiguous field/decl access in the presence of shadowing a compile error

[ifreund]

Currently Zig allows decls and fields of the same struct to share names. This is confusing, especially if the field in question is a function pointer:

const std = @import("std");

const Foo = struct {
 bar: fn () void,
 fn bar(foo: Foo) void {
 std.debug.print("decl bar called\n", .{});
 }
};

fn bar2() void {
 std.debug.print("field bar called\n", .{});
}

pub fn main() void {
 const foo = Foo{ .bar = bar2 };
 foo.bar();
}

The current rule is that the field shadows the decl, but this is non-obvious at the call-site if the user intended to call Foo.bar() instead of the function pointer stored in the field bar. It should be noted that this is technically not ambiguous as field always shadows the decl and the decl may be accessed with Foo.bar(&foo);. Nonetheless, I propose to make this a compile error as I don't think the ability to use the same name for fields and decls is a beneficial feature that outweighs the confusion and potential for errors caused by this situation.

See also: #705 #6966

[andrewrk]

The plan here is to follow the example set by decl shadowing: fields and declarations are allowed to shadow; however access must always be unambiguous. So the example given above would be a compile error.

[ifreund]

access must always be unambiguous. So the example given above would be a compile error.

As I explained above, this is already technically unambiguous if the (subtle) rules are understood. I assume your proposed change is to force field access to look unambiguous as well? @field(foo, bar) is still ambiguous as @field() works for decls as well despite its name (#3839).

[ifreund]

So I brought this up in the stage2 meeting today and it looks like one option to make this appear less ambiguous would be to implement the following behavior:

foo.bar(); // compile error
(foo.bar)(); // function pointer field call
Foo.bar(foo); // function decl call

I still feel like this isn't perfect though as the function pointer field may be accessed without calling it, and requiring it to be wraped in parentheses in e.g. @TypeOf((foo.bar)) seems nonsensical.

The only way I see to resolve this issue in a way I personally find satisfactory seems to be #6966 or similar.

[ominitay]

I personally believe that field/decl shadowing should eliminated from the language. I don't see shadowing here being either necessary or useful: it instead introduces ambiguity.