Hope this won’t get merged for several reasons, the main one being that slapping newly invented abbreviations onto every codebase component is a bad practice that severely restricts readability and makes the learning curve for newcomers only steeper.
As correctly pointed out by @cancernamepub visibility is enforced by @import of the source file regardless of compilation unit. Only pub declarations are carried over by the @import. Unfortunately, usingnamespace does not seem to help. If all the code fits into a single file presence or absence of pub visibility qualifier does not seem to matter.
The use of the term “compilation unit” is intentional because it’s referring to exactly the same concept: a Zcu represents a collection of Zig sources being compiled into a single object file. The difference compared to C is that in the latter, each source file generates a separate object, and hence each C source file is a separate compilation unit.
Yeah, my bad, I was thinking of the CU in the context of C. I do agree with the use of that term for Zig, it’s just that the abbreviated Zcu is obscuring that terminology and will take some time getting used to.
The fact that pub only affects visibility of @import-ed declarations is unfortunate. It mixes up logical and physical organization of the code. Mere moving a struct declaration between source files can result in compilation errors.
It did seem that way to me at first, too. I don’t believe this approach is that common, which is probably why it’s hard to see its merits right away. But I came to appreciate the fact that in Zig physical organization IS the logical organization of code. That way it inherently forces the source tree to reflect the code logic, rather than permitting arbitrary code structure.