Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Partially Matching Zig Enums

matklad.github.io

Post reply on HN
Print view View original

11–20 of 170 posts

Re: Partially Matching Zig Enums

#11

Post by anonymoushn »

dwattttt wrote: post #6
anonymoushn wrote: post #5

Earlier 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.

Well, for example you may have some functions which accept types and return types, which are not compatible with some input types, and indicate their incompatibility by raising an error so that compilation fails. If the program actually does not pass some type to such a function that leads to this sort of error, it would seem like a bug for the compiler to choose to evaluate that function with that argument anyway, in the same way that it would be a bug if I had said "template" throughout this comment. And it is not generally regarded as a deficiency in C++ that if the compiler suddenly chose to instantiate every template with every value or type, some of the resulting instantiations would not compile.

Re: Partially Matching Zig Enums

#12

Post by Sharlin »

dlahoda wrote: post #4

fn main() { if false { const _:() = panic!(); } } Fails to compile in Rust.

Sure, because it's compile-time code inside a (semantically) run-time check. In recent Rust versions you can do

    fn main() {
        const {
            if false {
                let _:() = panic!();
            }
        }
    }
which compiles as expected. (Note that if the binding were `const` instead of `let`, it'd still have failed to compile, because the semantics don't change.)

Re: Partially Matching Zig Enums

#13

Post by jeltz »

Ygg2 wrote: post #9
judofyr wrote: post #7

This 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`.

I disagree, I would say the error is in "comptime unreachable" or maybe the whole "switch (ab)".

Re: Partially Matching Zig Enums

#14

Post by diegocg »

judofyr wrote: post #7

This 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.

As someone who uses D and has been doing things like what you see in the post for a long time, I wonder why other languages would put attention to these tricks and steal them when they have been completely ignoring them forever when done in D. Perhaps Zig will make these features more popular, but I'm skeptic.

Re: Partially Matching Zig Enums

#15

Post by dwattttt »

anonymoushn wrote: post #11
dwattttt wrote: post #6

Earlier quoted context omitted.

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.

Well, for example you may have some functions which accept types and return types, which are not compatible with some input types, and indicate their incompatibility by raising an error so that compilation fails. If the program actually does not pass some type to such a function that leads to this sort of error, it would seem like a bug for the compiler to choose to evaluate that function with that argument anyway, i…

To take an extreme example, what if I asserted the Riemann hypothesis in comptime? It's relying on comptime execution to act as a proof checker.

Which is fine for small inputs and uses, but it's not something that would scale well.

Re: Partially Matching Zig Enums

#16

Post by [deleted] »

dwattttt wrote: post #15
anonymoushn wrote: post #11

Earlier quoted context omitted.

Well, for example you may have some functions which accept types and return types, which are not compatible with some input types, and indicate their incompatibility by raising an error so that compilation fails. If the program actually does not pass some type to such a function that leads to this sort of error, it would seem like a bug for the compiler to choose to evaluate that function with that argument anyway, i…

To take an extreme example, what if I asserted the Riemann hypothesis in comptime? It's relying on comptime execution to act as a proof checker. Which is fine for small inputs and uses, but it's not something that would scale well.

[deleted]

Re: Partially Matching Zig Enums

#17

Post by brabel »

diegocg wrote: post #14
judofyr wrote: post #7

This 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.

As someone who uses D and has been doing things like what you see in the post for a long time, I wonder why other languages would put attention to these tricks and steal them when they have been completely ignoring them forever when done in D. Perhaps Zig will make these features more popular, but I'm skeptic.

I was trying to implement this trick in D using basic enum, but couldn't find a solution that works at compile-time, like in Zig. Could you show how to do that?

Re: Partially Matching Zig Enums

#18

Post by 9029 »

dwattttt wrote: post #6
anonymoushn wrote: post #5

Earlier 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.

Nope, this is not relying on optimization, it's just how compile time evaluation works. The language guarantees "folding" here regardless of optimization level in use. The inline keyword used in the original post is not an optimization hint, it does a specific thing. It forces the switch prong to be evaluated for all possible values. This makes the value comptime, which makes it possible to have a comptime unreachable prong when switching on it.

There are similarities here to C++ if constexpr and static_assert, if those are familiar to you.

Re: Partially Matching Zig Enums

#19

Post by chrismorgan »

judofyr wrote: post #7

This 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.

What I’ve seen isn’t people disregarding Zig because it’s just another memory-unsafe language, but rather disqualifying Zig because it’s memory-unsafe, and they don’t want to deal with that, even if some other aspects of the language are rather interesting and compelling. But once you’re sold on memory safety, it’s hard to go back.

Re: Partially Matching Zig Enums

#20

Post by Sytten »

chrismorgan wrote: post #19
judofyr wrote: post #7

This 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.

What I’ve seen isn’t people disregarding Zig because it’s just another memory-unsafe language, but rather disqualifying Zig because it’s memory-unsafe, and they don’t want to deal with that, even if some other aspects of the language are rather interesting and compelling. But once you’re sold on memory safety, it’s hard to go back.

This is really the crust of the argument. I absolutely love the Rust compiler for example, going back to Zig would feel a regression to me. There is a whole class of bugs that my brain now assumes the compiler will handle for me.
Post reply on HN