Differences between ZON and Zig

kj4tmp · March 16, 2026, 6:41am

There are differences between ZON and Zig:

ZON has nan, inf, -inf literals, zig does not.

Side note: are -0.0 and +0.0 literals needed?

Should these differences be eliminated (add these literals to zig)?

Add those special float literals to zig
Remove those special float literals from zon
Do nothing and accept the difference between zig and zon

0 voters

IntegratedQuantum · March 16, 2026, 6:52am

I think the general movement is towards disallowing these states to make it easier to find bugs: Disallow NaN and inf for `comptime_float` · Issue #21205 · ziglang/zig · GitHub (accepted)
Proposal: Make floats non-NaN by default · Issue #11234 · ziglang/zig · GitHub (proposed)

rpkak · March 16, 2026, 6:59am

Here is another related accepted proposal:

github.com/ziglang/zig

introduce new float types; remove `@setFloatMode`

opened 12:28AM - 10 Mar 25 UTC

andrewrk

proposal accepted

Rather than a setting, there will be new float types: * `real16` * `real32` *… `real64` * `real128` These types guarantee `@sizeOf` but otherwise have **non-well-defined memory layout**. `@bitCast` is not allowed on this type, and they are not allowed in `extern` or `packed` structs. This is a conservative choice that may or may not be relaxed in a future proposal. These types are different than their `f16`, `f32`, `f64`, and `f128` counterparts in that: * They cannot store NaN, -inf, or +inf. * No operations can produce +inf or -inf. If they would, checked illegal behavior occurs instead. * No operations can produce NaN. If they would, checked illegal behavior occurs instead. * Saturating arithmetic can be used to avoid potential illegal behavior. * Cannot distinguish between positive or negative zero. * Arithmetic operations do not follow IEEE float semantics. They may: * Produce different results on different targets * Produce different results in different optimization modes * Use the reciprocal of an argument rather than perform division. * Perform floating-point contraction (e.g. fusing a multiply followed by an addition into a fused multiply-add). * Perform algebraically equivalent transformations that may change results in floating point (e.g. reassociate) * Any operation may use any rounding mode. Reals implicitly coerce into floats, however, `@realFromFloat` is required to convert a float to real, which invokes checked illegal behavior if the value is NaN, -inf, or inf. `@setFloatMode` is to be eliminated. Users would be encouraged to choose real types unless deterministic IEEE floating point semantics are required. Therefore, the floating point types would be renamed to `float16`, `float32`, `float64`, and `float128`.

kj4tmp · March 16, 2026, 7:09am

I think ZON should be capable of representing the semantics of IEEE floats, don’t you agree? If you expect a ZON formatted response from a server, what would you expect it to return for 0/0?

This also begs the question of if ZON should have error literals too… (error.InvalidRequest)

rpkak · March 16, 2026, 7:25am

The reason why these literals exist in zon, but not in zig, is that in zig, you can simply do std.math.nan(type)/std.math.inf(type), which is impossible in zon. So as long as float types in zig can represent inf and nan (which is required as long as zig floats should be compatible with e.g. c floats) and zon floats are compatible with zig floats, converting inf or nan to zon should result in something. Another idea I just had (I’m not sure if I like it) is to have something like -1/0, 0/0, 1/0 as zon literals.