4 ms·

Yes. For example in Rust it took a long time for floating point operations to be available at compile time and even now only a subset is. The reason is that a l

Yes. For example in Rust it took a long time for floating point operations to be available at compile time and even now only a subset is. The reason is that a lot of energy and thought went into the issue of producing identical output (and what identical precisely means ) even when compilation is on a different processor than where the target runs. As far as I know this is not a concern for Zig comptime.

chaz72 13d ago
Now I see this response, I responded to the other comment.
nvme0n1p1 13d ago
What's your source for this? Comptime Zig code can do pointer casts and whatnot, all emulated as if run on the target bitness/endianness/etc. And any operations that are undefined on the target platform result in a compile error. I've never had an issue cross-compiling.
- weinzierl 13d ago
  Endianness and pointer casts are the mechanical part and I would expect Zig to emulate them correctly. Other parts, like floats are harder. This is where a difference shows. Rust is like: "Sorry, since we cannot uphold our guarantees, no transcendentals for you at comptime ", whereas Zig is chill about that and let you have your transcendentals even if results may differ between comptime and runtime. Different mindsets.
  - simonask 13d ago
    Just to note, Rust has had compile-time floats for a while now, but yes.
    - weinzierl 13d ago
      Yes, but no transcendentals on floats. You can add them and the like but you cannot calculate the sine.
  - adrian_b 13d ago
    The guarantees could be provided, if there would be a way to ensure that the compiler uses the same standard math library that is used by the executable program that is created. This could be done, for instance, if the standard math library would be dynamically linked into the compiler, so the same library would be available for the compiled program.
    - weinzierl 13d ago
      If you disregard performance, yes. Unfortunately forcing softfloat everywhere would result in abysmal performance, so this is not an option.
rvrb 13d ago
there has been a ton of work on making comptime a pure and deterministic execution environment. I do not expect that work to stop. I don't know where you are getting the idea that it is not an important design consideration for the language. to expand, if two different host platforms cross compiling to the same target platform have different results, I am almost certain that would be considered a compiler bug. if you're pointing out that a runtime operation and a compile time operation might not agree, I'd be more interested in understanding when that would ever have any meaningful impact on anything. given the compilation is supposed to be deterministic, the difference can easily be addressed by comptime branching on target architecture in the rare case that it matters for your program.
- weinzierl 13d ago
  Determinism and host/target agreement are two different properties. I meant the second one. It's something Rust guarantees (without me having to take care of it e.g. by manually branching) and Zig does not.
  - rvrb 13d ago
    sure, it sounds like there is a difference here. I'm not aware of any stance by the Zig core team on the subject. I am genuinely interested in a place that this matters for a program, or any practical consequence this has for an end user of the language. no idea why your response was flagged originally.
    - weinzierl 13d ago
      The practical value is that moving a computation from runtime to compile time can then be purely an optimization, rather than potentially changing its semantics. Think generated lookup tables or numeric constants. Ideally f(x) means the same thing whether evaluated by the compiler or by the generated program.
      - chaz72 13d ago
        > Ideally f(x) means the same thing whether evaluated by the compiler or by the generated program. Absolutely, that’s why I wanted to know what types of things aren’t covered yet, and that’s also why I don’t share your certainty that they won’t be resolved later.
pjmlp 13d ago
In C++ as well, constexpr math introduced in C++23 has similar concerns regarding floating point accuracy.
dnautics 13d ago
Zig Comptime uses softfloat so it has architecture independent determinism. And the zig core team is absolutely concerned with bitwise determinism in the compiled artifacts, iirc this is why they rejected the sloppy bun PR to the compiler.
- weinzierl 13d ago
  Determinism and host/target agreement are two different properties. The Zig core team is apparently not concerned enough about the second point to forbid transcendentals at comptime and this is something that'd be hard to take back, because I'd break existing code.
  - torginus 13d ago
    Generally speaking, as a user of a language, stuff should just work while providing identical results to the target arch. Which means that when cross compiling from x86 to ARM, if lets say, transcendentals provide different results then always the target archs implementations should be used, even if they have to be emulated. If however, hypothetically, different x86 CPUs produce different results for transcendentals, and we can't control where the user will run our program, then imo the correct solution for the language is to provide a set of knobs for the user to communicate whether they favor accuracy or speed in this scenario. - but we can say there's no 'correct' decision in this case, only tradeoffs. Forbidding transcendentals is not a correct decision as it adds a ton of compiler complexity (you have to track which functions use them transitively), and baffling UX - the user finds that comptime doesn't work because the function he uses might use transcendentals somewhere down the chain.
    - weinzierl 13d ago
      The responsible approach is to wait before stabilizing a language feature until a consensus is reached and until we are confident we will not have to roll back or change the feature and break existing code. This is what Rust does. The discussion how to deal with transcendentals in Rust is ongoing and at some point there will be a conclusion.

chaz72 13d ago

Now I see this response, I responded to the other comment.

nvme0n1p1 13d ago

What's your source for this? Comptime Zig code can do pointer casts and whatnot, all emulated as if run on the target bitness/endianness/etc. And any operations that are undefined on the target platform result in a compile error. I've never had an issue cross-compiling.

weinzierl 13d ago
Endianness and pointer casts are the mechanical part and I would expect Zig to emulate them correctly. Other parts, like floats are harder. This is where a difference shows. Rust is like: "Sorry, since we cannot uphold our guarantees, no transcendentals for you at comptime ", whereas Zig is chill about that and let you have your transcendentals even if results may differ between comptime and runtime. Different mindsets.
- simonask 13d ago
  Just to note, Rust has had compile-time floats for a while now, but yes.
  - weinzierl 13d ago
    Yes, but no transcendentals on floats. You can add them and the like but you cannot calculate the sine.
- adrian_b 13d ago
  The guarantees could be provided, if there would be a way to ensure that the compiler uses the same standard math library that is used by the executable program that is created. This could be done, for instance, if the standard math library would be dynamically linked into the compiler, so the same library would be available for the compiled program.
  - weinzierl 13d ago
    If you disregard performance, yes. Unfortunately forcing softfloat everywhere would result in abysmal performance, so this is not an option.

rvrb 13d ago

there has been a ton of work on making comptime a pure and deterministic execution environment. I do not expect that work to stop. I don't know where you are getting the idea that it is not an important design consideration for the language. to expand, if two different host platforms cross compiling to the same target platform have different results, I am almost certain that would be considered a compiler bug. if you're pointing out that a runtime operation and a compile time operation might not agree, I'd be more interested in understanding when that would ever have any meaningful impact on anything. given the compilation is supposed to be deterministic, the difference can easily be addressed by comptime branching on target architecture in the rare case that it matters for your program.

weinzierl 13d ago
Determinism and host/target agreement are two different properties. I meant the second one. It's something Rust guarantees (without me having to take care of it e.g. by manually branching) and Zig does not.
- rvrb 13d ago
  sure, it sounds like there is a difference here. I'm not aware of any stance by the Zig core team on the subject. I am genuinely interested in a place that this matters for a program, or any practical consequence this has for an end user of the language. no idea why your response was flagged originally.
  - weinzierl 13d ago
    The practical value is that moving a computation from runtime to compile time can then be purely an optimization, rather than potentially changing its semantics. Think generated lookup tables or numeric constants. Ideally f(x) means the same thing whether evaluated by the compiler or by the generated program.
    - chaz72 13d ago
      > Ideally f(x) means the same thing whether evaluated by the compiler or by the generated program. Absolutely, that’s why I wanted to know what types of things aren’t covered yet, and that’s also why I don’t share your certainty that they won’t be resolved later.

pjmlp 13d ago

In C++ as well, constexpr math introduced in C++23 has similar concerns regarding floating point accuracy.

dnautics 13d ago

Zig Comptime uses softfloat so it has architecture independent determinism. And the zig core team is absolutely concerned with bitwise determinism in the compiled artifacts, iirc this is why they rejected the sloppy bun PR to the compiler.

weinzierl 13d ago
Determinism and host/target agreement are two different properties. The Zig core team is apparently not concerned enough about the second point to forbid transcendentals at comptime and this is something that'd be hard to take back, because I'd break existing code.
- torginus 13d ago
  Generally speaking, as a user of a language, stuff should just work while providing identical results to the target arch. Which means that when cross compiling from x86 to ARM, if lets say, transcendentals provide different results then always the target archs implementations should be used, even if they have to be emulated. If however, hypothetically, different x86 CPUs produce different results for transcendentals, and we can't control where the user will run our program, then imo the correct solution for the language is to provide a set of knobs for the user to communicate whether they favor accuracy or speed in this scenario. - but we can say there's no 'correct' decision in this case, only tradeoffs. Forbidding transcendentals is not a correct decision as it adds a ton of compiler complexity (you have to track which functions use them transitively), and baffling UX - the user finds that comptime doesn't work because the function he uses might use transcendentals somewhere down the chain.
  - weinzierl 13d ago
    The responsible approach is to wait before stabilizing a language feature until a consensus is reached and until we are confident we will not have to roll back or change the feature and break existing code. This is what Rust does. The discussion how to deal with transcendentals in Rust is ongoing and at some point there will be a conclusion.