i’m new to zig, and the type system seems quite unergonomic compared to other languages. where in rust you would have var_name as i32
, in zig you sometimes have @as(i32, @intCast(var_name))
, which, while is explicit, is a little too noisy for me. there are helper functions like
pub fn I32(T: anytype) i32 {
return @intCast(T);
}
which i’ve used, but i have never seen them in andrewrk’s codebases which i am learning zig from. i’ve been doing a lot of game development with raylib, which means juggling their frequent use of i32 and f32 parameters with usizes, which loops return and array indexes take in.
Hello,
unfortunetly helper functions are your best bet for now.
It really helps to have known destination type so you dont have to use @as()
everywhere.
But there are some nice ideas to make it better, especially for game dev purposes: Short math notation, casting, clarity of math expressions - #38 by andrewrk
That said, i have made relatively complex custom rescaling renderer for my game window in Zig and it was much less of a pain point then i tought at first. Actually i had much less bugs in the math logic, thanks to this verbosity of casting. (compared to my past much simpler stuff in C)
1 Like
I think that most of the time result location semantic is enough. It can take a bit of creativity to figure out how to write something elegant. Maybe you can show us some cases and we can try to help.
But if your code is really math-heavy then cast functions are indeed your best bet.
That’s exactly the purpose of imposing the verbosity: Less bugs.
1 Like
thanks for the advice, everybody. i’ve since looked over my code’s base structure and abstracted the few places which caused the cascading of types