Non-pub decl occasionally polluting the pub namespace

[vadim-za]

Zig Version

0.14.0-dev.1694+3b465ebec

Steps to Reproduce and Observed Behavior

Create and compile the following code distributed across the 4 files and 2 folders as the comments say.

/// ------- main.zig
const decls = @import("decls.zig");

pub fn main() void {
    _ = decls.get();
}

/// ------- decls.zig
pub const S = @import("decls/s.zig").S;
pub usingnamespace @import("decls/use_s.zig");

/// ------- decls/s.zig
pub const S = struct {};

/// ------- decls/use_s.zig
const decls = @import("../decls.zig");

// commenting out the following line avoids the compile error
const S = @import("s.zig").S;

pub fn get() decls.S {
    return .{};
}

Observe the following error:

src\decls\use_s.zig:7:19: error: ambiguous reference
pub fn get() decls.S {
             ~~~~~^~
src\decls.zig:2:5: note: declared here
pub const S = @import("decls/s.zig").S;
~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
src\decls\use_s.zig:5:1: note: declared here
const S = @import("s.zig").S;
^~~~~~~~~~~~~~~~~~~~~~~~~~~~

Now comment out the declaration of const S in use_s.zig. The code compiles now.

Expected Behavior

The code compiles in both cases

[mlugg]

This was an intentional simplification to the rules of usingnamespace, because the previous implementation was non-deterministic.

Note also #20663.

[vadim-za]

Is there any information to what exactly the simplification was? The error message is totally puzzling and leaving me clueless of what is wrong in the source code.

In particular, I was assuming that maybe usingnamespace now also includes the non-pub members, however that conjecture is refuted by replacing _ = decls.get(); in main.zig with _ = decls.S{};, which now compiles. So the ambiguity of decls.S seems totally random.

[mlugg]

Non-pub declarations are accessible if they are declared in the same file which is performing the namespace lookup. So, writing decls.S in use_s.zig can see the declaration of S in use_s.zig, but writing decls.S in a different file cannot.

These rules may be reviewed again if #20663 is rejected.

[vadim-za]

Upon thinking about it, it still looks pretty awkward. It's one and the same S, just accessed through two different paths. Why would that be ambiguous? And it seems to me that two different S wouldn't ever be able to create this kind of ambiguity. Anyway, probably indeed worth waiting for a decision on #20663.

Edit: the latter part of the statement was not correct, so nevermind.