3 ms·
> In case of Rust this is true, but you would have to restrict Zig’s semantics to something like Rust’s to make your idea workable. That's exactly the point.
by throwawaymaths 4y ago
> In case of Rust this is true, but you would have to restrict Zig’s semantics to something like Rust’s to make your idea workable.
That's exactly the point. You would be restricting zig's semantics within code that you've fenced. You claim it's not possible. Trivially it should be possible, because this is simply the equivalent of abstracting rusts compiler logic (and in the worst case scenario even it's type system, via annotations) to a sidecar step that is run at a different phase of building your code. Or, more generically, formalizing logic that a code reviewer is doing in their head to understand data lifecycles. Really, to support your impossibility claim: It's on you to give an example of zig code that wouldn't be analyzable.
- kaba0 4y agoI think we misunderstand each other on what is “inside-outside”. Sure, you can have a tiny “safe” block in zig, but that won’t be able to use any outside pointer safely, and I don’t see much point in that — is that what you mean? Because unless you say that, then no. Also surely you can write some zig to rust compiler (which mind you, will not compile most of your programs as the equivalent rust is not semantically correct), but there is not much point. Re code: let ptr = allocate(); if (undecideableProperty()) { destroy ptr; } print(*ptr); Insert any number of undecidable property there, one elegant example would be the Goldbach conjecture.
- throwawaymaths 4y agoIf any branch could destroy the pointer, you wouldn't be able to use it later, the static analysis would stop the build. No need to evaulate the undecidable.