Zig's new bitCast semantics and LLVM back end improvements (ziglang.org)

> Quite long devlog coming up, apologies—I got a little carried away with this one!

mlugg, please don't apologize for creating something I actually want to read. I'm drowning in low effort garbage, the in depth technical explanation is a refreshing breath of fresh air.

Might as well apologize for creating a language without a garbage collector, sure most people are unwilling to think, but some of us like nice things and are actually willing to apply effort.

Interesting read, even as someone who isn't using Zig.

I wonder, these arbitrary-width integers... Is it actually even really worth it? My intuition is to prefer manually packing/unpacking things instead (in any language, even C that has bit width for struct fields), because it gives me a better mental picture of the code that is actually generated. Particularly for something like an signed odd-bit integer - what kind of code gets generated for sign-extension, a presumably common operation?

Does anybody have other experiences with them, one way or the other?

> Consider, for instance, bitcasting a [2]u8 to a u16. Under the old semantics, the result of this operation depends on the target endian: on big-endian targets, the first array element became the 8 most significant bits, whereas on little-endian targets, the first array element became the 8 least significant bits. Under the new semantics, because we only care about logical bit representation (which is endian-agnostic), the operation behaves identically on every target:

This is a huge mistake. You would never expect something like bitCast to do this.

I don't understand this approach. Why change something so simple and low level to be complicated and high level?

Just don't allow casting to u24, as it makes no sense unless you define u24 to be u32 sized as I think c standard does.

I think this approach as an idea is bad but at least just add another built-in that implements this higher level idea to not break a simple expectation and current behavior?

This change + the existing packed struct logic will be great for working with bit packed binary headers w/o having to manually twiddle so much about the bit handling along the way.

OT: I'm always surprised at how popular Zig discussions get here, or Youtube and other medias.

Don't get me wrong, I love Zig and I think it's a great C replacement, but I'm very confused on why C3 or Odin rarely get any attention at all, despite being in the same C-replacement crowd.

But still surprised at what Zig does better than these other projects? Is Andrew much better at marketing/promoting the language? He's very hard to dislike.

Is pasting em-dashes everywhere some kind of inside joke?

These posts make you want not only to use Zig, but also to marry it.

No jokes aside, these posts are the best advertisements of the language.

And I truly like their AI stance.

FTA: “Under the new semantics, because we only care about logical bit representation (which is endian-agnostic), the operation behaves identically on every target: the first array element becomes the 8 least significant bits”

I wouldn’t call that endian-agnostic. It’s explicitly picking little-endian.

It also makes things look weird for beginners. I know how it works, but in the

  test "bitcast [2]u3 to @Vector(3, u2)"

example, turning two 3-bit values [abc def] into three 2-bit values [bc fa de] is way less intuitive than turning it into [ab cd ef].

Can I convert a 300-byte message to Base64 with a single instruction? Like:

  in: [300]u8;
  out: [800]u3;
  out = @bitCast(in);

[flagged]

Writing linkers must be incredibly rewarding - go has its own, there's mold, there's LLD, there's the OG GNU bfd LD and now Zig has one too! I am sure there's a Rust one too - Wild!

Every one of them is faster than the others too lol! Mold for one tries really hard to be GNU ld and to be useful as an independent linker most have to - I guess Zig/Go ones are purpose built so at least those don't duplicate GNU ld compatibility.

When I first found out about bit fields in C, I was left wondering what the order of bits was in a byte, eventually I convinced myself it doesn't matter, since the byte is the smallest I/O unit, and lived with the fact that casting between bitfields and bytes was UB (or unspecified, I can't remember), and as such, was another thing I wasn't suppossed to do when writing C.

All this to say that Zig just keeps cleaning up and giving well-defined semantics to warts I learned to live with in C.