[kps]

When I first played with Zig (and I haven't done more than play), I had a similar view. I suspect that the adoption of Zig in certain current C niches may be hampered by the inability to express things like the opaque pointer idiom, mandated by coding standards like CERT C and MISRA[ble] C.

I now think that an external tool is the way to go. C++ has field access control, but for some projects, that's not enough, so they have an external layer of access control, like Chromium DEPS (sample: https://source.chromium.org/chromium/chromium/src/+/main:ui/... )

And use cases of libraries are different. Perhaps most uses of library X use it as a black box and should never directly access structure fields, but project X′ integrates closely with X. That's hard to express in the language since it's hard to express purely within X at all. Maybe you need a `foo.@i_know_this_is_private_but_let_me_use_it_anyway(bar)`, like Python's underscore convention.

Or you have an external static analyzer using some sort of allow and deny rules. Maybe library X declares `Deny *` but project X′ overrides it with an `Allow X.foo.bar`. The rules can be explicit, automatically enforced, and subject to code review, so it's OK.