3 ms·

It's mildly offensive that u10000 is a builtin type but vec2f is not (also note that I am not asking for general operator overloading!). Which has dedicated CPU

It's mildly offensive that u10000 is a builtin type but vec2f is not (also note that I am not asking for general operator overloading!). Which has dedicated CPU instructions across all modern architectures, what's the relative usage frequency, what's the cost/benefit of each, etc etc... :( And we all know why u10000 is in there: because you have to have arbitrary-width integers when writing a compiler, so they figured eh, we'll just expose that because we have it already. Absolutely transparent compiler-programming (cf. rendering-programming) bias, almost nobody else needs that. And yeah, I get that Add(Add(Add(a, b), Mul(c, 3)), d) is possible, but come on... imagine if you had to write your normal "a + b + c * 3 + d" with ints/floats like that! What's that, suddenly people care, but nobody cares if it's not their field... Whatever, I will continue to look longingly at Zig for all the bits of C/C++ (and apparently Go, to try bring it back to the original topic) it solves, but missing the trivial and absolutely critical single feature to enable an entire class of performance-critical programming.

defen 3y ago
> And we all know why u10000 is in there: because you have to have arbitrary-width integers when writing a compiler You don't need them as a built-in type to write a compiler. They're there because LLVM was the original backend and you essentially get them for free (in the sense that the backend code generation is already handled for you, so why not include them).
bsder 3y ago
> It's mildly offensive that u10000 is a builtin type but vec2f is not u10000 exists only because we want u3, u7, and u13 as builtin types. u3, u7, and u13 are useful for embedded and systems programming.
tuhats 3y ago
> It's mildly offensive that u10000 is a builtin type but vec2f Zig does have builtin vec2f, it is spelt @Vector(2, f32).
- ForkMeOnTinder 3y ago
  @Vector is counterproductive for cases like vec2f, since it tries to force data into SIMD registers even when it would be more efficient to leave it in normal registers. In fact I've wondered in the past if Zig might end up slower than C for graphics code, if people misuse @Vector to get normal math operators back. For that reason I never use @Vector unless I already know what SIMD intrinsics I'd be writing in C.

defen 3y ago

> And we all know why u10000 is in there: because you have to have arbitrary-width integers when writing a compiler You don't need them as a built-in type to write a compiler. They're there because LLVM was the original backend and you essentially get them for free (in the sense that the backend code generation is already handled for you, so why not include them).

bsder 3y ago

> It's mildly offensive that u10000 is a builtin type but vec2f is not u10000 exists only because we want u3, u7, and u13 as builtin types. u3, u7, and u13 are useful for embedded and systems programming.

tuhats 3y ago

> It's mildly offensive that u10000 is a builtin type but vec2f Zig does have builtin vec2f, it is spelt @Vector(2, f32).

ForkMeOnTinder 3y ago
@Vector is counterproductive for cases like vec2f, since it tries to force data into SIMD registers even when it would be more efficient to leave it in normal registers. In fact I've wondered in the past if Zig might end up slower than C for graphics code, if people misuse @Vector to get normal math operators back. For that reason I never use @Vector unless I already know what SIMD intrinsics I'd be writing in C.