If you want to a zero sized struct field in an extern struct, it must also be extern. Is this a bug or a feature? 
// /tmp/tmp.zid
test {
_ = extern struct {
m: struct {},
}{};
}
zig 0.16:
$ zig test /tmp/tmp.zig
/tmp/tmp.zig:3:12: error: extern structs cannot contain fields of type 'tmp.test_0__struct_42975__struct_42976'
m: struct {},
^~~~~~~~~
I believe this is working as intended.
It is perplexing to regard a size 0 struct as a special case.
1 Like
Auto structs can include hidden data for debug/safety purposes, e.g verifying ptr cast. So you can not be sure a struct with no fields is 0 sized!
That is not currently the case but is planned.
3 Likes
Hidden data? How does that look?
Iâm imagining fields which are void in release builds but non-zero sized in debug builds. Or maybe bare union tags in debug builds.
Well itâs the compiler, so it can just add or remove things if it wants to.
While they will probably only exist in safe modes, the language doesnât require it.
Gotcha. I guess I can see how special casing them is akward for the compiler.
I guess I donât see how a user defined, zero sized type might not be zero sized though. And if it must always be zero sized, then extern or auto wouldnât seem to matter. Unless there are some language features making them incompatible.
you simply canât define a zero sized type with an auto struct, as the size is an implementation detail of the compiler.
And there is no reason âemptyâ auto structs should be exempt from hidden safety fields, they can be instantiated and used, even if they shouldnât be.
2 Likes
Ah ha! My use case is solved by using an enum (u0) which is extern compatible
.
it doesnt matter, but it is curious that you jumped over extern struct{}âŚ
Yes thats what I was using. Nothing wrong with extern struct - both are equal for my use case. Not really an ah-ha moment but I just didnât think to use an enum 