WingNews logo WingNews
top | item 32647814

(no title)

andolanra | 3 years ago

> This all works, people have been doing it for years in C, C++, Java, Rust, and more. In Zig, we can do better.

We can also do better in those other languages, too. For example, in Rust, I can use a crate like `bitfield` which gives me a macro with which I can write

    bitfield! {
        pub struct Color(u32);
        red, set_red: 0;
        green, set_green: 1;
        blue, set_blue: 2;
        alpha, set_alpha: 3;
    }
Don't get me wrong: it's cool that functionality like this is built-in in Zig, since having to rely on third-party functionality for something like this is not always what you want. But Zig is not, as this article implies, uniquely capable of expressing this kind of thing.

discuss

order

zppln|3 years ago

Is it something I'd ever want to rely on third-party functionality for?

jeroenhd|3 years ago

C has them and their implementation seems to be universally disliked. Using an external crate with an implementation that people do like, with the possibility to substitute another if you disagree, seems better than to force a specific implementation into the language (that people will then replace with external dependencies or that people will learn to avoid as a concept).

speed_spread|3 years ago

As long as the compiled code is just as efficient as it would be had it been built-in to the language, I don't see the issue? Bitfield ops are very low-level constructs that are only useful in very specific project types. Their portable usage can be tricky, it's not something a majority of coders should reach for.

That's the luxury of a standard build system: essential but rarely used features can be left out of the core language / lib because adding them back in is just a crate import away.

masklinn|3 years ago

Yes? If you have lots of bitfields and the convenience / readability is worth it, why wouldn’t you?