[dnautics]

no. You don't need private fields. All you have to do is analyze the code, harness the compiler to generate a time-dependent data dependency graph, and map allocation/frees/uses, if you can 'color' branches where data are shared you can also track and check to see there isn't an aliasing violation too.

it is easy to patch the zig compiler to enable this this (export the code graph; about 50 LOC). The analysis is much much harder to get right.

[afdbcreid]

This analysis is undecidable. There is a reason sound static analyzers (including languages like Rust) require in-code annotations.

[dnautics]

it is possible to do in-code annotations in zig, if you're clever. you can get pretty far without them too.

as an example, you can check for double free without ownership tagging, by being agnostic about who should free, and flagging if two nondisjoint code paths attempt to free the same allocation.

[AlotOfReading]

It seems like it'd be pretty reasonable to get something akin to polonius. I can write up an engine in zig if it'd help?

[dnautics]

start by examining zig-clr

[rcxdude]

It is only feasible to do this if the whole of the codebase idea designed to allow it, and it's still going to blow up in odd ways of you don't have a way to describe lifetimes in your interfaces. The magic of rust's design is that it turns this memory tracking into a local problem, such that you can design an interface and be sure that every use case is safe and verifiably so.