AstGen: disallow fields and decls from sharing names

[mlugg]

This is a mini-proposal which is accepted as a prerequisite for #9938. The standard library and compiler needed a few changes to obey the new rules. Most of these are a net gain for readability, I'd say.

---

I discussed this change a little with @jacobly0 after running into some of the more awkward migrations in the compiler codebase. We reached the conclusion that, even ignoring #9938 entirely, this is a desirable language change. That's because certain namespace accesses today have some inherent ambiguity:

• MyEnum.foo can refer to a declaration or an enum variant.
• MyUnion.foo can also refer to a declaration or an enum variant (coercible to the union if the payload is void).
• Even for structs, my_struct_val.foo() presents an ambiguity, since foo could be a function [pointer] field or a method. (This also applies to unions.)
• N/A for opaques because they don't have fields.

Today, Zig makes arbitrary choices for how to resolve these ambiguities. The first two examples prefer decls, and the enum variant can be accessed with an enum literal (.foo). Conversely, method call syntax prefers a field if available, in which case the method can be accessed with MyStruct.foo(my_struct_val). These rules are awkward; they don't align with Zig's general perspective here of emitting a compile error upon ambiguity. So, the rule introduced by this PR, while occasionally slightly awkward, sidesteps this ambiguity issue by accepting that there are situations where field and declaration namespaces are conflated, so these namespaces should avoid conflicting with one another.

[xdBronch]

if this change is only in astgen wont it still allow something like this?

const A = struct {
    foo: u8,
    usingnamespace B;
};
const B = struct {
    fn foo(_: A) void {}
};

is that intentional? is there an unofficial official consensus on usingnamespaces fate?

[mlugg]

Agh, fuck, you're right, I forgot about usingnamespace.

I'm inclined to go ahead with this PR anyway, and solve the usingnamespace case down the line if #20663 is ultimately rejected. We definitely do want the AstGen check, we just might also want a check in Sema if usingnamespace sticks around.

[andrewrk]

I think these "init" names are an unfortunate downgrade as a result of this breaking change, however, I have no suggestion to offer, and I think you found the best name given the new language constraints.

Related:

• allow implicitly casting T to tagged union when the union has a field and member type with matching names #995
• Field access of explicit tag type union should prioritize definitions over tag. #959

[mlugg]

Yeah, these were the ones that led me to discuss the change with Jacob. It's worth noting that these x86_64 ones were described by @jacobly0 as legacy, and their replacement doesn't have this problem.

[mlugg]

Release Notes

Fields and Declarations Cannot Share Names

Zig 0.14.0 introduces a restriction that container types (struct, union, enum and opaque) cannot have fields and declarations (const/var/fn) with the same names. This restriction has been added to deal with the problem that whether MyEnum.foo looks up a declaration or an enum field is ambiguous (a problem amplified by [Decl Literals](TODO LINK TO RELEVANT RELEASE NOTES SECTION)). Generally, this can be avoided by following the standard naming conventions:

const Foo = struct {
    Thing: Thing,
    const Thing = struct {
        Data: u32,
    };
};

-->

const Foo = struct {
    thing: Thing,
    const Thing = struct {
        data: u32,
    };
};