Re:Ziglings: Learn the Zig programming language by fixing ti...
by jeltz on Saturday February 13, 2021 @04:24PM
(#26127074)
Tow issues I have noticed with Zig: not as good type signatures for functions and not as good error messages. I am not sure if those are fundamental issues with Zig's apporach or if they can be fixed with more work.
[ Parent
| on HN ]
Re:Ziglings: Learn the Zig programming language by fixing ti...
by vram22 on Sunday February 14, 2021 @03:52AM
(#26130703)
Can you elaborate a bit on the first issue?
Re:Ziglings: Learn the Zig programming language by fixing ti...
by jeltz on Sunday February 14, 2021 @06:28PM
(#26137316)
Take for example the definition of floor(), how would an IDE or documentation generator see which types are supported? This is just imperative code which is executed at compile time and at least to me it is not obvious how to interpret it when generating the documentation. On the other hand in Rust it is almost always easy to see which types can be used where.
pub fn floor(x: anytype) @TypeOf(x) {
const T = @TypeOf(x);
return switch (T) {
f16 => floor16(x),
f32 => floor32(x),
f64 => floor64(x),
f128 => floor128(x),
else => @compileError("floor not implemented for " ++ @typeName(T)),
};
}
Re:Ziglings: Learn the Zig programming language by fixing ti...
by haberman on Monday February 15, 2021 @01:46AM
(#26139846)
This seems reasonable to me. It seems comparable to the following in C++:
template <class T> T floor(T x) { /* ... */ }
I think a documentation generator could display your Zig signature verbatim and a user could make sense of that.