Partially Matching Zig Enums
matklad.github.io
Partially Matching Zig Enums
1–10 of 170 posts
Re: Partially Matching Zig Enums
#2This post shows how versatile Zig's comptime is not only in terms of expressing what to pre-compute before the program ever runs, but also for doing arbitrary compile time bug-checks like these. At least to me, the former is a really obvious use-case and I have no problem using that to my advantage like that. But I often seem to overlook the latter, even though it could prove really valuable.
Re: Partially Matching Zig Enums
#3This post shows how versatile Zig's comptime is not only in terms of expressing what to pre-compute before the program ever runs, but also for doing arbitrary compile time bug-checks like these. At least to me, the former is a really obvious use-case and I have no problem using that to my advantage like that. But I often seem to overlook the latter, even though it could prove really valuable.
I love the idea, but something being "provable" in this way feels like relying on optimisations.
If a dead code elimination pass didn't remove the 'comptime unreachable' statement, you'll now fail to compile (I expect?)
Re: Partially Matching Zig Enums
#4fn main() {
if false {
const _:() = panic!();
}
Fails to compile in Rust.
Re: Partially Matching Zig Enums
#5This post shows how versatile Zig's comptime is not only in terms of expressing what to pre-compute before the program ever runs, but also for doing arbitrary compile time bug-checks like these. At least to me, the former is a really obvious use-case and I have no problem using that to my advantage like that. But I often seem to overlook the latter, even though it could prove really valuable.
I love the idea, but something being "provable" in this way feels like relying on optimisations. If a dead code elimination pass didn't remove the 'comptime unreachable' statement, you'll now fail to compile (I expect?)
A lot of Zig relies on compilation being lazy in the same sort of way.
Re: Partially Matching Zig Enums
#6Earlier quoted context omitted.
I love the idea, but something being "provable" in this way feels like relying on optimisations. If a dead code elimination pass didn't remove the 'comptime unreachable' statement, you'll now fail to compile (I expect?)
A lot of Zig relies on compilation being lazy in the same sort of way.
For the validity of the program? As in, a program will fail to compile (or compile but be incorrect) if an optimisation misbehaves?
That sounds as bad as relying on undefined behaviour in C.
Re: Partially Matching Zig Enums
#7This is one the reasons I find it so silly when people disregard Zig «because it’s just another memory unsafe language»: There’s plenty of innovation within Zig, especially related to comptime and metaprogramming. I really hope other languages are paying attention and steals some of these ideas.
«inline else» is also very powerful tool to easily abstract away code with no runtime cost.
Re: Partially Matching Zig Enums
#8fn main() { if false { const _:() = panic!(); } } Fails to compile in Rust.
Why would it? If I recall correctly, const and static stuff basically gets inlined at the beginning of the program.
Re: Partially Matching Zig Enums
#9This is one the reasons I find it so silly when people disregard Zig «because it’s just another memory unsafe language»: There’s plenty of innovation within Zig, especially related to comptime and metaprogramming. I really hope other languages are paying attention and steals some of these ideas. «inline else» is also very powerful tool to easily abstract away code with no runtime cost.
> «inline else» is also very powerful tool to easily abstract away code with no runtime cost.
Sure, but you lose the clarity of errors. The error wasn't in `comptime unreachable` but in `inline .a .b .c`.
Re: Partially Matching Zig Enums
#10Earlier quoted context omitted.
A lot of Zig relies on compilation being lazy in the same sort of way.
For the validity of the program? As in, a program will fail to compile (or compile but be incorrect) if an optimisation misbehaves? That sounds as bad as relying on undefined behaviour in C.
It's not an optimization. What gets evaluated via the lazy evaluation is well defined. Control flow which has a value defined at comptime will only evaluate the path taken. In the op example, the block is evaluated twice, once for each enum value, and the inner switch is followed at comptime so only one prong is evaluated.