3 ms·

I'm pretty sure Zig has no plans to ever become safe - by any sane sense of the word - so, yes, I would expect...

dnautics 3mo ago
zig does have plans to give access to IRs when stable so adding a borrow checker to zig will be even easier than it is now
- gpm 3mo ago
  This is cool and will likely enable some cool tooling. I don't think a borrow checker is likely to be in that tooling. Borrow checking requires shaping the code, and all the dependencies, into easily analyzable (and at least in rust's version annotated) patterns. You can't borrow check arbitrary code not designed for it without false positives.
  - slekker 3mo ago
    You can because all allocations are tracked and explicit
    - onlyrealcuzzo 3mo ago
      Allocations are less of a problem than aliases. Without affine/linear ownership - solving the aliasing problem is the Halting Problem. Rust didn't invent Affine Ownership just to make Rust hard. It did it because it's one of the only ways to have memory safety without a GC.
      - dnautics 3mo ago
        1. rust didnt invent affine ownership. 2. It's possible to bolt on to other languages (see ada). zig in particular is easy (disclaimer: i think, i haven't implemented it yet)
        onlyrealcuzzo 3mo ago
        > zig in particular is easy (disclaimer: i think, i haven't implemented it yet) I guess it's "easy" compared to other languages - but if you think it's "easy", we have different definitions of "easy". You could implement it, but it would look like efforts in Rust to get SPARK-like safety, and SPARK itself. It will essentially be a different language. You will not be able to work seamlessly with any regular Zig code. That may or may not be a problem if you're willing to assume you can just use it all unsafely and it works enough that things are fine. That's somewhat analogous to unsafe Rust. The difference with unsafe Rust is... That's a very small fraction of what you're using, not the vast majority of what you use. When you use a Rust crate - you generally do not expect that it could have infinite race conditions. It may have some unsafe code, but that should be the exception, not the norm. By all means, please build it. I'd consider using it [=
        dnautics 3mo ago
        > You will not be able to work seamlessly with any regular Zig code. That may or may not be a problem if you're willing to assume you can just use it all unsafely and it works enough that things are fine. that may be true, but it seems "not". to date, all of the patterns in zig-clr nudge you towards idiomatic zig and not away from it. i run tests on not-my-code (an unaltered version of an existing zig project -- you can see it's vendored in the "vendored/validate"), and it passes. still working through forestmq. and I'm planning a mechanism to let you reach into a function and "oracle" its safety parameters, probably most useful when someone else has written code that you know is ok but you cant tell them "hey make this work to pass my linter" Also remember that zig compiles as a single compilation unit so even if you draw in zig dependencies, unless they are hidden behind a .so, zig-clr will analyze the dependency code too.
        onlyrealcuzzo 3mo ago
        By all means - reach out when it's ready and I'll give it a test. I'm highly skeptical you can get it to work. If it was easy and optional and non-invasive and actually worked - the Zig team would almost certainly build it. But, even if it just mostly works - that would still be very useful if it's non invasive.
    - gpm 3mo ago
      That's not sufficient - consider the following pseudocode x = malloc(); if (opaque_cond()) free(x); if (other_opaque_cond()) use(x); Conditions can be opaque and non-analyzable due to rices theorem - in any turing complete language. This code is correct (or at least not memory unsound) if opaque_cond and other_opaque_cond are never both true. Otherwise it isn't. And functionally compiler analyses of whether conditions hold have to be trivial because using some form of theorem prover to decide of code is correct or not leads to code that is brittle against compiler version changes, and slow compile times. Thus opaque_cond could be as simple as `len == 0` and `other_opaque_cond` could be `len > 0` and it's unlikely you'd want the compiler to realize those are mutually exclusive (at the stage where it accepts programs, obviously during optimization it is very likely to take advantage of this). Rust solves this by simply rejecting the pattern. Very roughly forcing you to write if opaque_cond() { free(x) } else if other_opaque_cond() { use_x } (or something else where the program structure and not just the logic in the conditions guarantees correctness). Zig simply allows it and leaves it up to the programmer not to make a mistake. And as onlyrealcuzzo suggests aliases are where this type of analysis (accepting enough programs to be useful but still imposing enough structure you can prove correctness) is really tricky.
      - dnautics 3mo ago
        so yes it is possible to detect those patterns and ban them as unsafe, and have a"safety checked alternative. clr does this currently: https://github.com/ityonemo/clr#safety-oriented-architecture https://github.com/ityonemo/clr#safety-oriented-architecture
        dnautics 3mo ago
        i dont understand the downvotes here. the point of any safety checker is to flag and ban potentially unsafe code, and force the author to rewrite with existing language patterns that guarantee the desired safety parameters. in this case, zig has a first class nullable syntax that the checker can use ti guarantee correctness for, so a checker can deterministically sidestep this turing completeness issue, by squeezing indeterminate code into the knowably safer language idiom.
        3mo ago
    - deleted 3mo ago
      [deleted]
- Peaches4Rent 3mo ago
  Apologies for the noob question, but what is an IR?
  - dnautics 3mo ago
    intermediate representation. attempting to analyze zig code directly would be too hard (especially with comptime). on the way to the compiler backend, the compiler builds a simplified representation that only has "actually existing functions" and is very straightforward, e.g. function 10112: 0: argument 0 1: argument 1 2: argument 2 3: add 0, 1 4: store 2 5: call function 1342, (2, 4) 6: return 5 you can see how building a data dependency graph from this would be easy.

zig does have plans to give access to IRs when stable so adding a borrow checker to zig will be even easier than it is now

gpm 3mo ago
This is cool and will likely enable some cool tooling. I don't think a borrow checker is likely to be in that tooling. Borrow checking requires shaping the code, and all the dependencies, into easily analyzable (and at least in rust's version annotated) patterns. You can't borrow check arbitrary code not designed for it without false positives.
- slekker 3mo ago
  You can because all allocations are tracked and explicit
  - onlyrealcuzzo 3mo ago
    Allocations are less of a problem than aliases. Without affine/linear ownership - solving the aliasing problem is the Halting Problem. Rust didn't invent Affine Ownership just to make Rust hard. It did it because it's one of the only ways to have memory safety without a GC.
    - dnautics 3mo ago
      1. rust didnt invent affine ownership. 2. It's possible to bolt on to other languages (see ada). zig in particular is easy (disclaimer: i think, i haven't implemented it yet)
      - onlyrealcuzzo 3mo ago
        > zig in particular is easy (disclaimer: i think, i haven't implemented it yet) I guess it's "easy" compared to other languages - but if you think it's "easy", we have different definitions of "easy". You could implement it, but it would look like efforts in Rust to get SPARK-like safety, and SPARK itself. It will essentially be a different language. You will not be able to work seamlessly with any regular Zig code. That may or may not be a problem if you're willing to assume you can just use it all unsafely and it works enough that things are fine. That's somewhat analogous to unsafe Rust. The difference with unsafe Rust is... That's a very small fraction of what you're using, not the vast majority of what you use. When you use a Rust crate - you generally do not expect that it could have infinite race conditions. It may have some unsafe code, but that should be the exception, not the norm. By all means, please build it. I'd consider using it [=
        dnautics 3mo ago
        > You will not be able to work seamlessly with any regular Zig code. That may or may not be a problem if you're willing to assume you can just use it all unsafely and it works enough that things are fine. that may be true, but it seems "not". to date, all of the patterns in zig-clr nudge you towards idiomatic zig and not away from it. i run tests on not-my-code (an unaltered version of an existing zig project -- you can see it's vendored in the "vendored/validate"), and it passes. still working through forestmq. and I'm planning a mechanism to let you reach into a function and "oracle" its safety parameters, probably most useful when someone else has written code that you know is ok but you cant tell them "hey make this work to pass my linter" Also remember that zig compiles as a single compilation unit so even if you draw in zig dependencies, unless they are hidden behind a .so, zig-clr will analyze the dependency code too.
        onlyrealcuzzo 3mo ago
        By all means - reach out when it's ready and I'll give it a test. I'm highly skeptical you can get it to work. If it was easy and optional and non-invasive and actually worked - the Zig team would almost certainly build it. But, even if it just mostly works - that would still be very useful if it's non invasive.
  - gpm 3mo ago
    That's not sufficient - consider the following pseudocode x = malloc(); if (opaque_cond()) free(x); if (other_opaque_cond()) use(x); Conditions can be opaque and non-analyzable due to rices theorem - in any turing complete language. This code is correct (or at least not memory unsound) if opaque_cond and other_opaque_cond are never both true. Otherwise it isn't. And functionally compiler analyses of whether conditions hold have to be trivial because using some form of theorem prover to decide of code is correct or not leads to code that is brittle against compiler version changes, and slow compile times. Thus opaque_cond could be as simple as `len == 0` and `other_opaque_cond` could be `len > 0` and it's unlikely you'd want the compiler to realize those are mutually exclusive (at the stage where it accepts programs, obviously during optimization it is very likely to take advantage of this). Rust solves this by simply rejecting the pattern. Very roughly forcing you to write if opaque_cond() { free(x) } else if other_opaque_cond() { use_x } (or something else where the program structure and not just the logic in the conditions guarantees correctness). Zig simply allows it and leaves it up to the programmer not to make a mistake. And as onlyrealcuzzo suggests aliases are where this type of analysis (accepting enough programs to be useful but still imposing enough structure you can prove correctness) is really tricky.
    - dnautics 3mo ago
      so yes it is possible to detect those patterns and ban them as unsafe, and have a"safety checked alternative. clr does this currently: https://github.com/ityonemo/clr#safety-oriented-architecture https://github.com/ityonemo/clr#safety-oriented-architecture
      - dnautics 3mo ago
        i dont understand the downvotes here. the point of any safety checker is to flag and ban potentially unsafe code, and force the author to rewrite with existing language patterns that guarantee the desired safety parameters. in this case, zig has a first class nullable syntax that the checker can use ti guarantee correctness for, so a checker can deterministically sidestep this turing completeness issue, by squeezing indeterminate code into the knowably safer language idiom.
      - 3mo ago
  - deleted 3mo ago
    [deleted]
Peaches4Rent 3mo ago
Apologies for the noob question, but what is an IR?
- dnautics 3mo ago
  intermediate representation. attempting to analyze zig code directly would be too hard (especially with comptime). on the way to the compiler backend, the compiler builds a simplified representation that only has "actually existing functions" and is very straightforward, e.g. function 10112: 0: argument 0 1: argument 1 2: argument 2 3: add 0, 1 4: store 2 5: call function 1342, (2, 4) 6: return 5 you can see how building a data dependency graph from this would be easy.