[G4E]

Even the first argument "no hidden control flow" is disingenuous : either the object you are summing are complex and you have to call a custom function to define what "summing" means in that case (you need to provide the summing function), or those are a primitive type and you're just calling a function builtin the language itself. In every case, you are calling a function ...

[messe]

> or those are a primitive type and you're just calling a function builtin the language itself

You’re thinking at a different level of abstraction to the Zig developers. Summing a primitive type is going to be turned into a couple of machine opcodes (but no branch instruction) and will usually be constant time, whereas an explicit function call will require pushing pc to the stack and jumping elsewhere, executing any number of instructions once there, taking an arbitrarily long time, making it more difficult to reason about.

[mh7]

Does zig plan on not supporting microcontrollers or not using "/" for integer division?

Because on your typical arm mcu, x/y is a function call to a definitively non-constant time function.

And lets not forget soft-fp. Every single floating point op is a function call...

[defen]

A better way to think about it is: for a given line of code, how much context do you need in order to understand what function is actually going to be called? Yes, some compiler-rt or soft-fp function might get called but you know that's happening and what it does.

With most languages you need significantly more context than you do in Zig - in C you need to know what preprocessor shenanigans might be going on; in C++ pretty much anything could be happening (operator overloads, virtual functions, constructors, destructors, who knows what else). With Rust you need to know what traits are imported, and if proc macros are involved then anything goes.

[tosihakkeri]

Don’t you people have anything better to do?