Why isn't using *void in a struct field an error?

[Jarred-Sumner]

Zig Version

0.11.0-dev.4006+bf827d0b5

Steps to Reproduce and Observed Behavior

Let's say you're writing some C/C++ and without noticing, you have this in your Zig:

pub const Struct = struct {
   // woops! this should be *anyopaque
   field: *void,
   trash: u32 = 0,
};

pub export fn Struct__exported(f: *Struct) *anyopaque {
    return f.field;
}

test {
   _ = Struct__exported(undefined);
}

*void was replaced by *anyopaque many months ago, but this code compiled successfully.

zig test repro.zig
All 1 tests passed.

Is *void a valid alternative to *anyopaque? If yes, why are there two (which goes against the philosophy of only one way to do things)? If no, why does this code compile successfully?

Expected Behavior

The code should not compile successfully

[nektro]

discussion in #6706

[nektro]

prior to that pointer-to-zero-sized were still valid but also zero-sized

[Jarred-Sumner]

I can see an argument to be made for allowing *void as an "indirect" type, like pub fn MyType() { if (someCondition()) return void; return RealType; } and then having functions with fn function(arg: *MyType) where *MyType conditionally evaluates to *void

But are there any cases where writing *void as a type in a field isn't a mistake? I can't think of any reason (note that this implies a distinction between type literal names and type representations)

[Vexu]

More discussion in #12075.

[silversquirl]

*anyopaque did not replace *void. You're thinking of *c_void