As far as I know this is not a concern for Zig comptime.
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.
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.
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.
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.
It's something Rust guarantees (without me having to take care of it e.g. by manually branching) and Zig does not.
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.
As far as I’m aware, they do produce semantically identical results, but something like the specific bit pattern of a NaN value can theoretically vary, and people might do fun things like encoding extra information in those bits.
Nonetheless, if you use a comparison function for which all NaNs are equivalent, different CPU architectures that are standard-compliant must produce bitwise identical results for the same sequence of operations.
Differences appear mainly when the compilers generate different operations or in a different order. Moreover, transcendental functions are computed using various approximations by the standard library, so if you use different libraries on different computers, you will get different results.
However, these are differences caused by software, not by hardware, and they happen even on the same computer when you use different versions of a compiler or of a standard library. Therefore such differences can be eliminated, if desired.
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.
From what I understand, there is hope for sqrt but there is no consensus on transcendentals.
Rust is concerned about memory-safety, yes, but the only strict requirement for memory-safety when it comes to const-evaluation is as follows: "The only guarantee the type system needs is that evaluating `some_crate::SOME_CONST` will produce consistent results if evaluation is repeated in different compilation units" ( https://rust-lang.github.io/rfcs/3514-float-semantics.html ).
Beyond that, from a philosophical standpoint, Rust takes great pains to ensure that const functions produce identical results regardless of whether or not those functions are called at compile-time or at runtime. Rust has adopted this stance because it wants to reserve the right to opportunistically evaluate const-capable functions at compile time, as a performance optimization, even if the user has not explicitly asked for it (for that matter, Rust also does its best to const-evaluate non-const functions when it can). Because of this, Rust's assumption is that users would be annoyed if their program's visible behavior depends on whether or not the optimizer has exercised its discretion to evaluate a specific function at compile-time.
However, this is only a guideline, not a strict guarantee. There is one exception to the above rule: "when a floating-point operation produces a NaN result, the resulting NaN bit pattern is some deterministic function of the operation’s inputs that satisfies the constraints placed on run-time floating point semantics. However, the exact function is not specified, and it is allowed to change across targets and Rust versions, and even with compiler flags. In particular, there is no guarantee that the choice made in const evaluation is consistent with the choice made at runtime."
In other words, calling the `.to_bits()` function on a floating-point value that happens to be NaN is allowed to produce a different result at runtime than it does at compile-time (note that all compile-time evaluations are guaranteed to always produce the same result for a given toolchain version for a given target, as required above).
This exception is made because otherwise otherwise it would be basically impossible to support floating-point math at all, thanks to the way various platforms have implemented their floating-point functions in practice.
In contrast, Zig doesn't have such a philosophical compunction against a function's result being determined by whether or not it's being evaluated at compile-time, as shown by the existence of the `@inComptime` builtin. But Zig does still broadly attempt to make comptime deterministic, including going so far as to forbid I/O, though I don't see where any specific guarantees are documented in the Zig reference.
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.
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.
* floating point differences between the build machine and the target. By far the most common
* endiannes - code assumes little median runs on big endian
There’s other more subtle issues that can crop up but those are the big two.
Not saying I agree though - those can happen anyway when you run on two different machines anyway.
In Rust we can expand what is possible at compile time without breaking existing code because we took a very careful approach only stabilizing what we are sure about. Some things will probably never be possible at compile time in Rust.
Zig is much more powerful but that also means they cannot take stuff away without breaking existing code and making comptime more restricted. So it is unlikely Zig will ever become like Rust in that regard, but that is ok - just different approaches.
For one of my crates I needed to have a build script make a bunch of lookup tables as separate files for me to `include_bytes!` because at the time I couldn't generate a bunch of floating point conversions in const.
The biggest constraint today on Rust's constant evaluation compared to where you'd expect is that trait implementations can't ever be constant, this obviously means you can't call SomeTrait::function in your constant, even if you can see the implementation of SomeTrait::function and if it were not a trait it'd obviously be constant -- but it also means sugar like Rust's for loop, which de-sugars into trait invocations, can never be constant today.
I think we can expect that to get fixed in the relatively near future, but I'd have said that last year too so what do I know.
If you have C++ experience you'd probably want a lot more. C++ is allowed to allocate inside constant evaluation, and I believe in C++ 26 it's now even allowed to persist the allocation to runtime rather than being required to always clean up during compilation, so that's a much bigger set of crazy things you can do at compile time.
Yep, that was my annoyance.
Const allocation is possible in Rust as an unstable feature. Not sure if you can persist it to runtime, though you can persist a reference which will become a static reference. I think it being unstable is why I needed `include_bytes!`.