To be clear, I was talking about a use case, not all use cases.
There are very real times where you have to support all 4 bytes, there are others where other drivers require you to restrict the domain of discorse.
It doesn't change the value/cost of bit casting in a language with arbitrary bit width languages, especially when combined with the fact that int overflows are detectable illegal behaviour and you have saturating and wrapping operators.
This is in addition to the ease of using packed structs I mentioned above.
A list of some advantages:
* Zig's arbitrary-sized integers have a fully defined ABI for padding
* Allows for strict domain modeling using them as platform independent refinement types
* Precise memory packing, allowing more utilization of register space etc...
* OOB compile time checks
* Bit masking optimization, where sequential changes to packed values are often merged into a small number of and/or masks
To move to a more information theory example:
DNA nucleotides (A, C, G, T) represents quaternary state pairs.
If you wanted to store an array of 1,000 DNA nucleotides, each symbol is one of 4 bases, requiring exactly 2 bits of information. The Shannon Information would be: 1000 * 2bits = 2000 bits.
With uint8_t this would take 8k bits, vs 2k bits of u2. That is 300% more for uint8_t.
It is still horses for courses, but as an example consider 12-bit sensor reading in a standard u16, the data type allows invalid states. To ensure safety, requires manual defensive logic throughout your program in the traditional C/Rust/...
That traditional model in zig:
fn processSensor(value: u16) !void {
if (value > 4095) return error.InvalidSensorData; // Extra logic branch
// ... logic ...
And the lower overall Kolmogorov complexity (cherry picked) form:
fn processSensor(value: u12) void {
// Zero validation boilerplate code required here
C23 does have _BitInt types for structs which can help if bit packing is your primary need, IMHO it doesn't offer the same advantages.
As an example, and I may be wrong, but I think you cant easily perform checked arithmetic or use standard overflow operations on individual C bit-fields without copying them out into standard standard types (like int), modifying them, masking them, and copying them back.
With Zig the invariant is maintained implicitly at the type layer, removing runtime validation branches, error paths, and testing code
Does it solve all problems, no. Is @bitCast, a zero runtime overhead, compile-time checked bit reinterpretation and [3]u8 \to u24 useless and silly, no.