ZigのbitCastセマンティクス刷新とLLVMバックエンドの大幅な改善について

Zig言語におけるbitCastのセマンティクスが新しくなり、あわせてLLVMバックエンドの最適化と機能強化が実施されました。

かなり長い開発ログになりますが、すみません。ちょっと書きすぎてしまいました！

mluggさん、私たちが本当に読みたいと思っているものを書いたことに対して謝る必要なんてないですよ。低品質なゴミ記事ばかりで溺れそうになっている身としては、深い技術解説は本当に清涼剤です。

それならいっそ、ガベージコレクターのない言語を作ったことに対しても謝ればどうですか。確かに多くの人は深く考えたがらないでしょうけど、私たちは良いものが好きだし、実際それなりに手間をかけることも厭わないので。

Zigを使っていない身ですが、興味深く読めました。

ところで、この任意のビット幅を持つ整数についてですが…本当に導入する価値があるんでしょうか？直感的には、手動でパッキングやアンパッキングを行う方を好みます（どんな言語であれ、ビット幅を指定できるCの構造体フィールドであっても）。その方が、実際に生成されるコードのイメージを掴みやすいからです。特に、符号付きの奇数ビット整数なんてどうでしょう。符号拡張のような、おそらく頻繁に行われる操作に対して、どんなコードが生成されるのか気になります。

この辺りについて、何らかの経験がある人はいますか？

例えば、[2]u8をu16にbitcastする場合を考えてみてください。以前のセマンティクスでは、この操作の結果はターゲットのエンディアンに依存していました。ビッグエンディアンなら最初の配列要素が上位8ビットになり、リトルエンディアンなら下位8ビットになっていました。新しいセマンティクスでは、論理的なビット表現（エンディアン非依存）のみを考慮するため、どのターゲットでも動作は同一になります。

これは大間違いだよ。bitCastにこんな挙動を期待する人なんていない。

なぜこういうアプローチなのか理解できない。なぜシンプルで低レイヤーであるべきものを、複雑で高レイヤーなものに変えるのか？

C標準のようにu24をu32サイズとして定義しない限り、u24へのキャストなんて意味がないんだから許可しなければいいだけでは。

考え方自体がダメだと思うけれど、せめてシンプルな期待や現在の挙動を壊さないように、この高レベルなアイデアを実装する別の組み込み関数を追加すればいいのでは？

この変更と既存のpacked structのロジックが組み合わされば、ビットパッキングされたバイナリヘッダーを扱うのがすごく楽になりそう。途中でビット操作を細かくいじる必要がなくなるのは素晴らしい。

余談だけど、ここでZigの話題がこれほど盛り上がるのがいつも不思議なんだよね。Youtubeとか他のメディアでもそうだけど。

誤解しないでほしいんだけど、Zigは大好きだし、最高のC言語代替だと思ってる。でも、同じC言語代替を目指すC3やOdinがほとんど注目されない理由がよくわからないんだ。

Zigは他のプロジェクトより何が優れているんだろう？Andrewのマーケティングやプロモーション能力が群を抜いてるだけなのかな？彼のことは嫌いになれないんだけどさ。

あちこちにエムダッシュ（—）を貼り付けるのって、何か業界内の内輪ネタか何か？

この投稿を読むと、Zigを使いたくなるどころか、Zigと結婚したくなるね。

冗談はさておき、これらの投稿はこの言語の最高の広告になっているよ。

それに、彼らのAIに対するスタンスも心から支持する。