Thoughts on working with numbers in Zig

oskarbh · December 14, 2025, 9:15am

Thoughts on working with numbers in Zig

Disclaimer: NOT a native English speaker, NOT an expert programmer, NOT an
expert on Zig.

First of all I do not want this to be some kind of rant, but just to provide
some constructive criticism of what I consider an otherwise near 10/10
programming and development experience.

Now that I have a few months of hobby-programming in Zig under my belt,
including a little stupid hobby game (far from anything “real”), I feel like
sharing my one and probably only real complaint about the Zig programming
language:

Working with numbers in Zig.

The language refuses to guess the intent of the programmer and automatically
cast numbers, lest there is no possibility of information-loss. This sounded
good to me in theory, but in practice, it has turned into a seemingly endless
source of frustration. It is not like other language safety features like a
strong type system or a “borrow-checker”, that you eventually learn and then
they stop nagging you as much. Numbers is Zig will continue to nag you forever!

Below is an example of code, that Zig will refuse to compile:

    for (0..10) |i| {
        const position = m.vec3(i * 1.5, i * 1.5, i * 1.5);
        try backend.drawCube(position, .{}, rotation, "material-name");
    }

Why? Because i is an unsigned 64 bit number, and you are not allowed to
multiply that with a floating point number. Well… I am sorry, but I did not
ask for an unsigned 64 bit number, I just asked you to count from 0 to 9, and
draw cubes with an offset.

This kind of compiler-behavior just feels condescending to me. Like the
programmer cannot be trusted with not causing some kind of bug whenever numbers
are involved. Zig is not like that with other things like memory management.

There are many other examples, I just picked one. Another irritating instance
of working with numbers in Zig, is when you find yourself casting the same
number back and forth just to please the compiler.

And while it probably saves us from making a mistake once in a while, I believe
it to be a net-negative to the development process. Here are some reasons:

It makes programming less fun or more tedious than it has to be.
Messes with the natural readability of mathematical expressions, like these
two examples:

Natural:

a = b / c;

Working with numbers in Zig:

a: f32 = @as(f32, @floatFromInt(b)) / c;

Which I believe to make it harder to debug the parts of your code which contain
lots of math, like a graphics shader (which, luckily, we write in other
languages).

As an aside, I have noticed that writing parsing (eg. during Advent of Code) and
statemachines (as is often useful in things like games), is particularly
pleasant in Zig (especially the labeled switch). And I cannot help but wonder,
if the reason for that, is that the language designers write a lot of that kind
of code. In that case, maybe I can hope that the Zig core team will include
someone who deals a lot with math.

Thank you for reading my (not a rant-) post.

vulpesx · December 14, 2025, 10:03am

The zig team is all for improving the experience with maths, but they don’t want to sacrifice clarity in the process.

It is a balance they are actively working on, at least the theory if not implementing it.

This should address a large part of the issues

github.com/ziglang/zig

allow integer types to be any range

opened 10:31PM - 29 Nov 19 UTC

andrewrk

breaking proposal

Zig already has ranged integer types, however the range is required to be a sign…ed or unsigned power of 2. This proposal is for generalizing them further, to allow any arbitrary range. ```zig comptime { assert(i32 == @Int(-1 << 31, 1 << 31)); assert(u32 == @Int(0, 1 << 32)); assert(u0 == @Int(0, 1); assert(noreturn == @int(0, 0)); } ``` ---- Let's consider some reasons to do this: One common practice for C developers is to use `-1` or `MAX_UINT32` (and related) constants as an *in-bound* indicator of metadata. For example, the stage1 compiler uses a `size_t` field to indicate the ABI size of a type, but the value `SIZE_MAX` is used to indicate that the size is not yet computed. In Zig we want people to use [Optionals](https://ziglang.org/documentation/master/#Optionals) for this, but there's a catch: the in-bound special value uses less memory for the type. In Zig on 64-bit targets, `@sizeOf(usize) == 8` and `@sizeOf(?usize) == 16`. That's a huge cost to pay, for something that could take up 0 bits of information if you are willing to give up a single value inside the range of a `usize`. With ranged integers, this could be made type-safe: ```zig const AbiSize = @Int(0, (1 << usize.bit_count) - 1); const MyType = struct { abi_size: ?AbiSize, }; var my_type: MyType = undefined; test "catching a bug" { var other_thing: usize = 1234; my_type.abi_size = other_thing; // error: expected @Int(0, 18446744073709551615), found usize } ``` Now, not only do we have the Optionals feature of zig protecting against accidentally using a very large integer when it is supposed to indicate `null`, but we also have the compile error helping out with range checks. One can choose to deal with the larger ranged value by handling the possibility, and returning an error, or with `@intCast`, which inserts a handy safety check. How about if there are 2 special values rather than 1? ```zig const N = union(enum) { special1, special2, normal: @Int(0, (1 << u32) - 2), }; ``` Here, size of N would be 4 bytes. ---- Let's consider another example, with enums. Enums allow defining a set of possible values for a type: ```zig const E = enum { one, two, three, }; ``` There are 3 possible values of this type, so Zig chooses to use `u2` for the tag type. It will require 1 byte to represent it, wasting 6 bits. If you wrap it in an optional, that will be 16 bits to represent something that, according to information theory, requires only 2 bits. And Zig's hands are tied; because currently each field requires ABI alignment, each byte is necessary. If #3802 is accepted and implemented, and the `is_null` bit of optionals becomes `align(0)`, then `?E` can remain 1 byte, and `?E` in a struct with `align(0)` will take up 3 bits. However, consider if the enum was allowed to choose a ranged integer type. It would choose `@Int(0, 3)`. Wrapped in an optional, it actually could choose to use the integer value 3 as the `is_null` bit. Then `?E` in a struct will take up 2 bits. Again, assuming #3802 is implemented, Zig would even be able to "flatten" several enums into the same integer: ```zig const Mode = enum { // 2-bit tag type Debug, ReleaseSafe, ReleaseFast, ReleaseSmall }; const Endian = enum { // 1-bit tag type big, little, }; pub const AtomicOrder = enum { // 3-bit tag type Unordered, Monotonic, Acquire, Release, AcqRel, SeqCst, }; pub const AtomicRmwOp = enum { // 4-bit tag type Xchg, Add, Sub, And, Nand, Or, Xor, Max, Min, }; const MyFancyType = struct { mode: Mode align(0), endian: Endian align(0), atomic_order: AtomicOrder align(0), op: AtomicRmwOp align(0), }; ``` If you add up all the bits of the tag type, it comes out to 10, meaning that the size of MyFancyType would have to be 2 bytes. However, with ranged integers as tag types, zig would be able to flatten out all the enum tag values into one byte. In fact there are only 21 total tag types here, leaving room for 235 more total tags before MyFancyType would have to gain another byte of size. ---- This proposal would solve #747. Peer type resolution of comptime ints would produce a ranged integer: ```zig export fn foo(b: bool) void { // master branch: error: cannot store runtime value in type 'comptime_int' const x = if (b) -10 else 100; // proposal: @typeOf(x) == @Int(-10, 101) } ``` ---- With optional pointers, Zig has an optimization to use the zero address as the null value. The `allowzero` property can be used to indicate that the address 0 is valid. This is effectively treating the address as a ranged integer type! This optimization for optional pointers could now be described in userland types: ```zig const PointerAddress = @Int(1, 1 << usize.bit_count); const Pointer = ?PointerAddress; comptime { assert(@sizeOf(PointerAddress) == @sizeOf(usize)); assert(@sizeOf(Pointer) == @sizeOf(usize)); } ``` One possible extension to this proposal would be to allow pointer types to override the address integer type. Rather than `allowzero` which is single purpose, they could do something like this: ```zig comptime { assert(*addrtype(usize) i32 == *allowzero i32); assert(*addrtype(@Int(1, 1 << usize.bit_count)) == *i32); } ``` This would also introduce type-safety to using more than just 0x0 as a special pointer address, which is perfectly acceptable on most hosted operating systems, and also typically set up in freestanding environments as well. Typically, the entire first page of memory is unmapped, and often the virtual address space is limited to 48 bits making `@Int(os.page_size, 1 << 48)` a good default address type for pointers on many targets! Combining this with the fact that pointers also have alignment bits to play with, this would give Zig's type system the ability to pack a lot of data into pointers which are annotated with `align(0)`. ---- What about two's complement wrapping math operations? Two's complement only works on powers-of-two integer types. Wrapping math operations would not be allowed on non-power-of-two integer types. Compile error.

for the float side

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`.

this thread had some ideas that andrew liked, aswell as some of his ideas.

oskarbh · December 15, 2025, 9:21am

Not sure I 100% understand, but would these changes increase or decrease “fighting” the compiler/type system? What if all APIs are going to use their own custom number type? Would you not have the problem exaggerated?

Btw, I hope we won’t get the names “real32, float32”. I’m sure we all can remember what r and f stand for in r32, f32.

vulpesx · December 15, 2025, 9:29am

Nope, an api will either have a technical maximum that they will be able to more accurately encode into types, currently they need an error if their maximum doesn’t happen to be log2.
Or the more likely case is they will be generic over the type.
Also, ranged integers will be able to coerce to other ranges if the other range fully encompasses the original range, e.g. 0 to 10 can coerce to -50 to 50.

This is such a small issue, but I would prefer the more verbose names to highlight the distinction, also for the visually impaired; r and f are quite similar.

oskarbh · December 15, 2025, 9:36am

Alright I hope you are right :).

vulpesx · December 15, 2025, 9:44am

Me too :D!

In all seriousness, I can’t see any reason an API will take a range that does not reflect the min/max they support. Such things the caller needs to deal with already.

If an API did use a dishonest range, then it’s just bad code, entirely the fault of who wrote the API.

Feel free to prove me wrong :D.

matklad · December 15, 2025, 12:12pm

Huh, there’s something I haven’t realized before!

My knee jerk reaction was to say something like

Well, you can’t represent every u64 losslessly as f64, so it would be odd if u64 was implicitly casted to f64. You could imagine iteration syntax like for (0..10.0) |f| which would iterate floats, but that’s also a can of worms, because, for sufficiently large float numbers, a + 1.0 == a.

But then I realized that I can think about i * 1.5 not as implicitly converting i to f64, but rather as multiplying a floating point number by an integer. This seems like a good shift of perspective? Converting u64 to f64 is lossy, so it’s good that we don’t do that. But multiplying f64 by u64 can actually be done precisely, because the loos of precision is already encoded in f64.

It is a bit like

var a: u64 = 10;
var b: i64 = 9;
const less: bool = a < b;

Although u64 and i64 represent different subsets of numbers, and you can’t losslessly convert one into another, it still is logically valid to ask which number is larger.

So, thanks, I think I am now in favor of allowing mixed floating/integer arithmetics (while still disallowing implicit coercions) based on fundamentals. Though, I haven’t written any numeric code in Zig, so I don’t have “in practice” opinion here.

tholmes · December 15, 2025, 12:59pm

I do think that if you’re capturing a for loop with a comptime-known range, the result type should be comptime_int.
I think the idea is that it might feel like a rug-pull if you switch to a runtime-known range and suddenly it doesn’t coerce as well as it used to, but I personally feel like Zig programmers are mature enough to recognise why this happened.

vulpesx · December 15, 2025, 1:04pm

That would essentially be an inferred inline which defeats the purpose of explicitly not using inline to let the optimiser decide.
Though the optimiser could turn it back into a loop if it thinks it’s better.
IDK how well it would do in that regard, re-rolling a loop doesn’t seem like a high priority to put effort into making the optimiser good at it.

Quin · December 15, 2025, 1:55pm

This is such a small issue, but I would prefer the more verbose names to highlight the distinction, also for the visually impaired; r and f are quite similar.

I’m not sure I get exactly what you mean here? Perhaps I misunderstood you/am not the visually impaired group you’re referring to (I’m totally blind and I’m sure lots of low-vision people use Zig, maybe it’s a visual thing), but as a screen reader user, f64, f32, f16 all having the same letter makes more sense than r for some of them.

vulpesx · December 16, 2025, 12:00am

I think you misunderstand, the ‘r’ isn’t arbitrary, there are big differences between a floating point number and a “real” number.

See this link for more details https://github.com/ziglang/zig/issues/23173

I was stating that I would prefer the names from the proposal: real32 and float32 over r32 and f32. Because visually, the longer names are more distinct. On further thought, I also think the longer names have more distinct sounds, though your opinion would be more valid here.

I shouldn’t be talking on behalf of a group I am not in. If there are any visually impaired (not totally blind) on here, then they should share their opinion.

It is just something that comes to mind as I heard some talk about how their impairment and programming languages interact.

But even people who aren’t visually impaired, I think, would have a harder time distinguishing r32 and f32 at a glance compared to the longer names.

Quin · December 16, 2025, 12:25am

Ooh okay, sorry, what you said makes much more sense now. I agree with you, I’d also prefer real32/real64 as a fully blind screen reader user

gwenzek · December 16, 2025, 6:56pm

Adding for (0..10) |i: i16| to the language would be really useful.

jmctagger · December 17, 2025, 4:45am

I would definitely take advantage of that, and can’t see disadvantages; could somebody highlight any disadvantages (perhaps other than the “it’s just unnecessary sugar” types, which are easily anticipated)?

Srekel · December 17, 2025, 5:14am

oskarbh · December 17, 2025, 7:54am

Thank you! That is exactly what I was thinking.

Srekel · December 17, 2025, 8:53am

A slightly more constructive post: Here is the zig issue (not sure if it will survive?) where Andrew posts that this will not get fixed.

github.com/ziglang/zig

Proposal: Infer type on ranged for loops from the type of the range values instead of defaulting to usize

opened 01:41AM - 22 Feb 23 UTC

closed 08:18PM - 10 Apr 23 UTC

BanchouBoo

Ranged loops defaulting to usize only makes sense when it's paired with a slice …or array iteration, in any other case there isn't really any good reason for it that I can think of, especially when the values used aren't `comptime_int`s. The following is the behavior I would expect from the types on ranged for loops: ```zig // i is comptime_int, and thus won't work because this is a runtime loop for (0..10) |i| {} // i is a comptime_int, but works fine because the loop is inlined inline for (0..10) |i| {} // i is a u8 for (0..@as(u8, 100)) |i| {} // i is a usize for (slice, 0..) |item, i| {} // i is a u16 for (@as(u8, 0)..@as(u16, 10000)) |i| {} // i is a u8, since it's required for the start of the range to be a lower number than the end of the range it's guaranteed that i will not overflow // if it's later decided that decrementing ranges will be allowed, then i should instead be a u16 for (@as(u16, 0)..@as(u8, 100) |i| {} ``` In discussion on this topic in the discord, the idea of putting the type on the capture was also floated: ```zig for (0..10) |i: u32| {} ``` But I think basing it off the type of the values used in the range itself makes much more sense, personally. There was also a suggestion to infer the integer type to the smallest type that will fit the range when using `comptime_int` to define the range. ```zig // i is u4 for (0..10) |i| {} ``` But requiring an explicit type in there somewhere feels more "correct" to me, and I feel that the uses where you know both ends of the range at comptime and aren't iterating over an array or storing the number in a constant somewhere that can be give a type are pretty uncommon in practice.

Dok8tavo · December 17, 2025, 12:39pm

This might reopen once the ranged integers make their appearance though, we could loop through a ranged integer.