3 ms·

> Zig can easily be more correct than unsafe code in Rust. Surely you're joking, because zig is a joke. As recently as 0.9-rc2 (and probably to this day) `{ .x

> Zig can easily be more correct than unsafe code in Rust. Surely you're joking, because zig is a joke. As recently as 0.9-rc2 (and probably to this day) `{ .x = if (false) { X(); } }` sometimes calls X. It is not possible to be "more correct" in such a language. Zig inspired me to think deeply about comptime evaluation and how it could be made into a coherent language, and in that respect it is a useful toy language, but no more. (In zig the comptime idea is incoherent: You cannot run ordinary zig code at comptime because of core differences in behavior. For example, there's no allocation allowed, except that code which appears literally in a comptime block can sometimes append arrays together; but this still means you can't run ordinary code.)

josephcsible 4y ago
When exactly would that call X? Can you post or link to a whole program where it does?
- puffoflogic 4y ago
  It's a known issue, idk, look it up in the github issues. https://github.com/ziglang/zig/issues/3882 https://github.com/ziglang/zig/issues/3882 is related but not quite the same thing. ETA: Oh this is even better: `if (false)` code can (as of 0.10) run even outside field assignment: https://github.com/ziglang/zig/issues/12040 https://github.com/ziglang/zig/issues/12040 Like I said, joke language. I define that as a toy language which is badly broken by design. Kind of like LOLCODE except I doubt LOLCODE runs `if (false)` code. More issues with `if`: https://github.com/ziglang/zig/issues/10349 https://github.com/ziglang/zig/issues/10349 https://github.com/ziglang/zig/issues/8952 https://github.com/ziglang/zig/issues/8952 https://github.com/ziglang/zig/issues/4491 https://github.com/ziglang/zig/issues/4491 https://github.com/ziglang/zig/issues/5230 https://github.com/ziglang/zig/issues/5230 https://github.com/ziglang/zig/issues/6444 https://github.com/ziglang/zig/issues/6444 https://github.com/ziglang/zig/issues/7097 https://github.com/ziglang/zig/issues/7097
  - anonymoushn 4y ago
    > https://github.com/ziglang/zig/issues/12040 https://github.com/ziglang/zig/issues/12040 This one is quite funny. Normally you'd use `if (a) ... else |b| ...` if the type of `a` was an error union, and you'd get the `if` branch if it was not an error and the `else` branch if it was an error. So I suspect that there's a coercion from bool to some error union here. Error unions with lazily computed error sets are allowed, and (as a result of this or of other choices about the ergonomics of conditionally-compiled code that would be made of #typedefs in C) error unions with empty error sets are allowed. Wow.
  - runald 4y ago
    As someone considering whether to learn rust or zig next for hobby projects, this does seem a pretty big deal breaker for zig, at least in its current state. But since zig still hasn't really even reached the 1.0.0, it is expected to have compiler bugs like this? Or do you believe this is something that can't be fixed due to fundamental language design?
    - kprotty 4y ago
      It's not expected to have miscompilation bugs like this by 1.0. These are bugs in the stage1 (original C++) compiler implementation, not language design issues as the poster claims. The language still has design issues that are being addressed (result location, async, etc.) but they're unrelated to `if` bugging out in this case. The stage1 compiler is currently being phased out for the stage2 compiler (Zig implementation). As of current master branch, stage1 is disabled by default (can be re-enabled with `-fstage1`) in favor of stage2.
      - puffoflogic 4y ago
        Stage2 is like a Band-Aid on an amputee. It is built with stage1. Any compiler built such that `if (false)` branches can run will also miscompile code, even if its source is 100% correct. (Spoiler alert: its source will not be 100% correct.)
        4y ago
- anonymoushn 4y ago
  I am only moderately surprised by this, because I have seen some less egrigious intermittent miscompilations in stage1 such as this one: https://github.com/ziglang/zig/issues/11786 https://github.com/ziglang/zig/issues/11786 I cannot provide the full program in which it failed, and the small programs I tried did not cause it to fail at the time. I sort of expect these things to be fixed though. Like, eventually both Zig and unsafe Rust will actually have defined semantics, and eventually expressions containing `if (false) { X(); }` will not call X, and so on. Edit: after seeing the linked issue in a sibling comment, this is even less surprising. stage1's handling of basically any complex expression in struct/tuple literals is quite bad. I've mostly had it crash the compiler, but it's not surprising that it can also just evaluate incorrectly. It seems plausible that the actual solution to all this is to use stage2 instead, but we cannot move all of our programs to stage2 today because we use async.

josephcsible 4y ago

When exactly would that call X? Can you post or link to a whole program where it does?

puffoflogic 4y ago
It's a known issue, idk, look it up in the github issues. https://github.com/ziglang/zig/issues/3882 https://github.com/ziglang/zig/issues/3882 is related but not quite the same thing. ETA: Oh this is even better: `if (false)` code can (as of 0.10) run even outside field assignment: https://github.com/ziglang/zig/issues/12040 https://github.com/ziglang/zig/issues/12040 Like I said, joke language. I define that as a toy language which is badly broken by design. Kind of like LOLCODE except I doubt LOLCODE runs `if (false)` code. More issues with `if`: https://github.com/ziglang/zig/issues/10349 https://github.com/ziglang/zig/issues/10349 https://github.com/ziglang/zig/issues/8952 https://github.com/ziglang/zig/issues/8952 https://github.com/ziglang/zig/issues/4491 https://github.com/ziglang/zig/issues/4491 https://github.com/ziglang/zig/issues/5230 https://github.com/ziglang/zig/issues/5230 https://github.com/ziglang/zig/issues/6444 https://github.com/ziglang/zig/issues/6444 https://github.com/ziglang/zig/issues/7097 https://github.com/ziglang/zig/issues/7097
- anonymoushn 4y ago
  > https://github.com/ziglang/zig/issues/12040 https://github.com/ziglang/zig/issues/12040 This one is quite funny. Normally you'd use `if (a) ... else |b| ...` if the type of `a` was an error union, and you'd get the `if` branch if it was not an error and the `else` branch if it was an error. So I suspect that there's a coercion from bool to some error union here. Error unions with lazily computed error sets are allowed, and (as a result of this or of other choices about the ergonomics of conditionally-compiled code that would be made of #typedefs in C) error unions with empty error sets are allowed. Wow.
- runald 4y ago
  As someone considering whether to learn rust or zig next for hobby projects, this does seem a pretty big deal breaker for zig, at least in its current state. But since zig still hasn't really even reached the 1.0.0, it is expected to have compiler bugs like this? Or do you believe this is something that can't be fixed due to fundamental language design?
  - kprotty 4y ago
    It's not expected to have miscompilation bugs like this by 1.0. These are bugs in the stage1 (original C++) compiler implementation, not language design issues as the poster claims. The language still has design issues that are being addressed (result location, async, etc.) but they're unrelated to `if` bugging out in this case. The stage1 compiler is currently being phased out for the stage2 compiler (Zig implementation). As of current master branch, stage1 is disabled by default (can be re-enabled with `-fstage1`) in favor of stage2.
    - puffoflogic 4y ago
      Stage2 is like a Band-Aid on an amputee. It is built with stage1. Any compiler built such that `if (false)` branches can run will also miscompile code, even if its source is 100% correct. (Spoiler alert: its source will not be 100% correct.)
      - 4y ago
anonymoushn 4y ago
I am only moderately surprised by this, because I have seen some less egrigious intermittent miscompilations in stage1 such as this one: https://github.com/ziglang/zig/issues/11786 https://github.com/ziglang/zig/issues/11786 I cannot provide the full program in which it failed, and the small programs I tried did not cause it to fail at the time. I sort of expect these things to be fixed though. Like, eventually both Zig and unsafe Rust will actually have defined semantics, and eventually expressions containing `if (false) { X(); }` will not call X, and so on. Edit: after seeing the linked issue in a sibling comment, this is even less surprising. stage1's handling of basically any complex expression in struct/tuple literals is quite bad. I've mostly had it crash the compiler, but it's not surprising that it can also just evaluate incorrectly. It seems plausible that the actual solution to all this is to use stage2 instead, but we cannot move all of our programs to stage2 today because we use async.