Re:Why Zig over C for Systems Programming
by pron on Friday November 13, 2026 @01:20PM
(#50487542)
Note that it's not that Zig is opposed to (user-controlled) operator overloading; it's opposed to (user-controlled) overloading of all symbols: The resolution of `foo` in `foo(x)` should not depend on the type of `x`. The issue is not the operators but the overloading, and Zig wants to prevent (user-controlled) overloading of any kind. This makes some things less convenient and other things more convenient.
[ Parent
| on HN ]
Re:Why Zig over C for Systems Programming
by tialaramex on Friday November 13, 2026 @03:13PM
(#50489004)
> The resolution of `foo` in `foo(x)` should not depend on the type of `x`
This depends on how you're squinting at this word "resolution".
Remember on a modern CPU an XOR R1 R1 does not result in an ALU operation, the decoder understands this idiom and just renames a zero'd register as R1, whereas of course it can't do that for say XOR R2 R3 because that's an actual XOR operation. So if "resolution" means "exactly what happens on the CPU" apparently there is no such facility provided even in assembler.
So apparently we mean only that it should have, in some sense, the same effect. I think the fact Rust is OK with
assert!("Goose".contains('o'))
assert!("Goose".contains("Goo"))
assert!("Goose".contains(&['a', 'e', 'i', 'o', 'u']))
It's not about okay or not okay. Zig is designed to prevent any user code from being implicitly called, or for the resolution of user code to be done implicitly. It's not about what the CPU does internally, but whether you're able to tell, from reading the code of a single subroutine, which operations could be done, whether stack frames can be created etc.. This has pros and cons, and for some people the pros outweigh the cons and for others, the other way around, and that's why different programming languages need to prioritise different things when they target different users.