Zigのコンパイル時計算(comptime)で「できないこと」まとめ！え、マジ？

えーと、波括弧とreturn文をなくせば、普通の型定義じゃん。型から型への関数としてジェネリック型をモデル化するのはSystem Fそのもので、1975年に遡るよ。型レベルのTuring完全なプログラミングは、TypeScriptからScala、Haskellまで、多くの言語で一般的だし。
ここで革新的なのは命令型の型レベルプログラミングだと思うなー。型レベルプログラミングをサポートする言語って、たいてい関数型言語か、型レベルでは関数型言語なんだよね。確かに面白いけど、革命的とまでは言えない気がする。

これって型レベルプログラミングじゃなくて、タームレベルプログラミングなんだよね。型のための別の言語がないってのがポイント。
関数型か命令型かは関係ないよ。それと、他の主要な機能がcomptime/partial evaluationを通じて直接表現されてるってのも重要。ジェネリック、マクロ、条件付きコンパイルの3つが大きな例かな。

＞This is one half of the innovation、 dependent-types lite。”それってdependent typesじゃないよ。Dependent typesは値に依存する型のこと。関数への引数が型か値だけなら、kind polymorphismだよ。
＞The second half is how every other major feature is expressed directly via comptime/partial evaluation、 not even syntax sugar is necessary. Generic、 macros、 and conditional compilation are the three big ones。”シンタックスシュガーがないのは些細なことだと思うけどね。

＞ Dependent types are types that depend on values。”こんな感じ？
fn f(comptime x: bool) if (x) u32 else bool { return if (x) 0 else false; }

タッチスクリーンを使ってキーボードをなくすデザインが、タッチスクリーンが他の場所で使われていたとしても斬新だってことに気づけないのは、デザインを理解してないってことだよ。
汎用的なコンパイル時メカニズムを使って、ジェネリクス/テンプレート、インターフェース/typeclasses、マクロ、条件付きコンパイルのような特殊な機能を避けた言語を教えてよ。そしたらその言語は革命的だって言うよ。
これらの機能を単一の機能（ASTマクロじゃないもの）に置き換えるのが斬新だってわからないのも信じられないな。

でもZigのcomptimeは、君が言った機能を完全に実装してるわけじゃないよね。それが元の記事で言ってること。タッチスクリーンでキーボードをなくすのは、タッチスクリーンのキーボードにキーがないなら、あんまりすごくないってことだよ。
不完全な実装を数えるなら、Cプリプロセッサがジェネリクス/テンプレート、インターフェース/typeclasses、マクロ、条件付きコンパイルを包含すると言えるかも。

＞The important thing is that the feature performs the duty of those other features。”タッチスクリーンにキーボードがなくてもキーボードの代わりになるって言うようなもんかな。大事なのは他の機能の役割を果たすことだよ。
＞If you say that incomplete implementations count、 then I could argue that the C preprocessor subsumes generics/templates、 interfaces/typeclasses†、 macros、 and conditional compilation。”CプリプロセッサのパワーがZigのcomptimeと完全に同じだと仮定しても、2つの問題があるよ。
まず、Cプリプロセッサは別のメタ言語。Zigのcomptimeの重要な点は、メタ言語がオブジェクト言語と同じ言語だってこと。
次に、マクロが他のすべての機能の役割を果たすことができるのは当然。

＞The important thing is that the feature performs the duty of those other features。”Zigのcomptimeは、Rust（とかJava、C#、Swiftなど）のジェネリクスがすること全部できないよね。Zigのcomptimeで作る”generics”は、インスタンス化されるまで型チェックされないから。
Zigのメタプログラミング機能は、DがZig登場の10年以上前に徹底的に探求したメタプログラミング機能のスピンオフだよ。

＞Zig doesn’t allow for the inference and type-directed method resolution that Rust or the above languages do”まあ、Zigはオーバーロードも許可してないし、comptimeに関係なく常に明示性を選択してるから、それは設計と一貫性があると思うよ。
＞Here’s an experiment. Start with D and start removing features: GC, the class system, exceptions, etc. etc. Do you get to something that’s more or less Zig modulo syntax?
Dがどうやってこれをやるか見てみたいな。comptime変数の概念は、”metalanguage”とオブジェクト言語がほぼ同じ言語であるという点で不可欠だね。

＞Dにはコンパイル時変数のアナロジーが見つからなかったんだけどさ。
Dのコンパイル時変数はこんな感じになるかな。
　enum v ＝ foo(3);

enumの初期化はConstExpressionだから、コンパイル時に評価されないとダメなんだよね。
Dのコンパイル時関数パラメータはこんな感じ。
　int mars(int x)(int y) ｛ … ｝

最初のパラメータリストはコンパイル時パラメータで、2番目は実行時パラメータ。
Dには型スイッチ文はないけど、static-if文で同じことができるよ。
　static if (is(T ＝＝ int)） ｛ … ｝
　else static if (is(T ＝＝ float)） ｛ … ｝

Static Ifは常にコンパイル時に評価されるんだ。IsExpressionは型に対してパターンマッチングするんだよ。

＞Dは2007年頃にコンパイル時関数実行(CTFE)を始めたんだって。
パイオニアだって？Forthは1970年代にあったし、Lispは1960年代のどこか(最初のバージョンにあったかどうかは知らないから断言はしないけど)にあったし、他にもっと古い例があるかもね。

君がこの機能を一年中ベタ褒めしてるのが理解できないんだよね。君は言語実装者なのにさ。
「YはただのXだ」って言えるのはクールだよね。美術館とかで遠くから見る分には。でも、毎日使うとなるとちょっとね。JavaのinterfaceからHaskellのtypeclassまで色々あるけど、実装しちゃえばあとは動くじゃん。Comptime型だと、Tをcomptimeに持ってきて、そこで動くかどうか確認しないといけないって聞いたんだけど。先見の明がないと動かないかもしれない。
それは嫌だな。Genericsとかparametric polymorphismとか、コンパイルが通ったらあとは動いてほしいんだよ。＜T＞があれば、サプライズなしにTを突っ込みたい。YがただのXかどうかは、優先順位が低いんだよね。Genericsとかが全部Xの下にあるかどうかもどうでもいい。もっと宣言的に言語を使わせてよ。
君が30億台のデバイスにインストールされてない言語をアカデミックだって批判してた時は、自分が理想主義的な方だと思ってたんだけどね。今はよく分からなくなってきたよ。
[1] https://news.ycombinator.com/item?id=24292760
[2] ScalaはJVM上にあるから、技術的にはカウントされるのかな？

僕がベタ褒めしてるのは、Zigのデザインが革命的だからだよ。プログラミング言語で完全に新しいデザインを見るのは珍しいし、学びやすくてローレベルプログラミング向けな言語なら特にね。
機能が良いかどうか判断するまで10～15年待つけど、悪いと判断するのはもっと早いことが多いかな。
＞Comptime型だと、Tをcomptimeに持ってきて、そこで動くかどうか確認しないといけないって聞いたんだけど。先見の明がないと動かないかもしれない。
でも、それは全部コンパイル時に行われるんだよ。他の特殊な機能もチェックされる時と同じようにね。
＞Genericsとかparametric polymorphismとか、コンパイルが通ったらあとは動いてほしいんだよ。
それもコンパイル時にチェックされるよ。コンパイルが通れば、Genericsみたいに動くよ。
＞もっと宣言的に言語を使わせてよ。
それは良いと思うよ。言語の好みは美的感覚だと思うし、デザインを客観的に評価するのは難しいと思う。結局は個人の好みとか、開発者やライブラリの有無、成熟度とかの言語外の要因で決まることが多いよね。
＞今はよく分からなくなってきたよ。
個人的には、ZigとかRustを重要なソフトウェアに使うのは考えられないな。実績がないからね。でも、新しいデザインは面白いと思うよ。僕の美的感覚に合うものもあるしね。

＞でも、それは全部コンパイル時に行われるんだよ。他の特殊な機能もチェックされる時と同じようにね。
＞…
＞それもコンパイル時にチェックされるよ。コンパイルが通れば、Genericsみたいに動くよ。
違うよ。Zigでcomptime型を使うライブラリを使う時、僕のコンパイルがうまくいくとは限らないんだ。ライブラリの作者が僕が使う型(とかコンパイル時の入力)でテストしたかどうかに左右されるからね。[1] それはJavaとかHaskellでは問題ないんだ。ライブラリがMaryで動けば、Johnでも動く。型入力が何であれね。
＞それは良いと思うよ。言語の好みは美的感覚だと思うし、デザインを客観的に評価するのは難しいと思う。結局は個人の好みとか、開発者やライブラリの有無、成熟度とかの言語外の要因で決まることが多いよね。
美的感覚に逃げないでよ。僕が言ってるのは、具体的で客観的なユーザー体験のトレードオフだよ。
[1] https://strongly-typed-thoughts.net/blog/zig-2025#comptime-i…

＞違うよ。Zigでcomptime型を使うライブラリを使う時、僕のコンパイルがうまくいくとは限らないんだ。ライブラリの作者が僕が使う型(とかコンパイル時の入力)でテストしたかどうかに左右されるからね。[1] それはJavaとかHaskellでは問題ないんだ。ライブラリがMaryで動けば、Johnでも動く。型入力が何であれね。
言ってる意味がよく分からないな。Genericsだって型パラメータに制限(例えばZigのtypeclassとかJavaの型境界)があるし、全ての型で動くわけじゃないでしょ。どちらの場合も、自分の型が境界に合うかどうかはコンパイル時に分かるよね。
Haskell/Javaの方が宣言的なのは確かだけど、それは美的感覚の問題だよね。ComptimeはC++テンプレートともHaskell/Java genericsとも違うし。どんなことでもそうだけど、特に本当に新しいアプローチは、万人に合うわけじゃない。Java, Haskell, Rustもそうだしね。だからといって、Zigのアプローチが面白くないわけじゃない。僕はRustのデザインが好きじゃないけど、面白くないわけじゃないし、Zigのアプローチはもっと新しいんだ。

Comptimeについて何が不満なのか分からないな。君がやりたいこと(generic, parametric polymorphism, slotting ＜T＞, etc)は全部comptimeでできるじゃん。Comptimeが褒められてるのは、他の言語の多くの機能を置き換えるシンプルなメカニズムだからだよ。Comptimeはシンプルで使いやすいし、日々のプログラミングで気にせず使えるよ。

誰かZigスタイルのマクロをCommon Lispに移植した人いる？

それってLispではデフォルトのことじゃないの？コードはデータだから変換できるじゃん。

Lispは強力だけど、静的型がないとオーバーロードみたいな基本的なことすらできないし、型(カスタム型の場合)をチェックして分岐する方法を自分で作らないといけないんだよね。

Zig の comptime には客観的に議論の余地があるけど、主観的には明確な欠点があって、Zig コミュニティはそれを zig build でコードを文字列として生成して、後で @imported してコンパイルすることで克服してるんだよね。
実際には”zig build”時の評価って感じ。だから、もっと自由度が高くて、実行時間に制限がなくて（@setEvalBranchQuota がない）、IO もできる（DB スキーマとかネットワーク検索とか）別の ‘comptime’ ステージがあるんだ。でも、現在のコンパイルで Zig の型を値として生成する自由はなくなるんだよね。その代わりに、ターゲットでコンパイルされたセマンティクスから入力構文に落として、文字列にして、将来のコンパイルコンテキストにまた入れる自由があるんだ。
昔、Perl と Tcl を C で繋いでた時、Tcl で生成した Perl の文字列を渡すのを思い出すよ。確かに動くけど、嬉しくないんだよね。コードで見えない別の ”macro” ステージ（@import）があるんだ。
Zig コミュニティの連中が自分たちを縛り付けるのが好きなのが、マジで理解できない。どんな新しい自傷行為をみんなに押し付けたいのかって議論は、マジで不快だわ。

＞Zig コミュニティの連中が自分たちを縛り付けるのが好きなのが、マジで理解できない。どんな新しい自傷行為をみんなに押し付けたいのかって議論は、マジで不快だわ。”
個人的には、コンパイラが完全に自分自身から外にアクセスできるなんて考えはマジで恐ろしい（ネットワークやデータベースにアクセス？マジかよ？）。
それは 100% ビルドシステムの仕事じゃん。
テキストファイルを生成して結果をコンパイラに戻すのが最良の方法かどうかは議論の余地があるけど、コンパイラが受け取って生成するものは完全に決定論的であるべきだよね。

＞個人的には、コンパイラが完全に自分自身から外にアクセスできるなんて考えはマジで恐ろしい（ネットワークやデータベースにアクセス？マジかよ？）。”
ここで言う ”自分自身” って何？ 静的な ”外部” ソースにアクセスすること？ 動的に生成された ”外部” ソースにアクセスすること？ そのファイルがビルドシステム/ビルドプロセスで派生情報として生成された場合、バージョン管理下に置く？ そうじゃないなら、俺と同じくらいヤバい？
一部のプロセスには鋭利なツールが必要で、常に扱うのを恐れてはいられないんだよ。鈍器しかないなら、C++ のことわざを知ってるだろ？
＞しかし、コンパイラが取得して生成するものは完全に決定論的である必要があります。”
Zig コミュニティは ‘zig build’ を ”コンパイルステップ” として扱ってるから、コンパイラが最終的に取得するものは ”コンパイル時、えーと、zig build 時” に決定されるんだ。コンパイラが取得するもの、つまり zig build が同じユーザー向けのプロセス内で生成するものは、決定論的じゃないんだ。
どうしてそうなるの？ インターフェースを生成することは、合理化されたプロセスの一部にしたいことなんだよ。C インターフェースを満足させるには、zig の ’translate-c’ を含む zig build 時のマルチステッププロセスに移行することになる。その出力を Zig ファイルにインポートするんだ。誰かがそれを comptime で暗黙的に行うのと（実際には今そうだけど）違って扱うと思う？

＞Zig コミュニティは ‘zig build’ を ”コンパイルステップ” として扱ってるから、コンパイラが最終的に取得するものは ”コンパイル時、えーと、zig build 時” に決定されるんだ。コンパイラが取得するもの、つまり zig build が同じユーザー向けのプロセス内で生成するものは、決定論的じゃないんだ。”
完全に決定論的なビルドシステムなんて、明示的にピン留めするプロセスを経ない限りないよ。実際には、ほとんどすべてのコンパイラは決定論的だよ（例えば、gcc は自分自身を 3 回再構築し、最後の 2 つがバイト単位で同一であることを確認する）。”zigmeson”（依存関係を解決して生成）と ”zigninja”（静的なリソースに対してコンパイラを呼び出すだけ）を区別する必要があるかもしれないけど、”zig build” が ”ビルドシステム” にディスパッチし、”zig”/”zig cc” が ”コンパイラ” にディスパッチするという事実は変わらない。
＞C インターフェースを満足させるには、zig の ’translate-c’ を含む zig build 時のマルチステッププロセスに移行することになる。その出力を Zig ファイルにインポートするんだ。誰かがそれを comptime で暗黙的に行うのと（実際には今そうだけど）違って扱うと思う？”
それは全く別の問題だけど、問題を完璧に示してる。
問題は、@cImport() が同じファイルに対して 2 つの異なるモジュールから呼び出せることなんだ。3 つあったらどうなる？ 異なるバージョンが必要になったらどうなる？ 以前の @cImport がファイルの翻訳方法を変更したらどうなる？ それに対してリンク時最適化をどうやる？
これが、コンパイラがすでに解決済みの静的なリソースで実行される必要がある理由なんだ。ビルドシステムが SAT ソルバーを呼び出してゴルディアスの結び目を解くのは構わない。コンパイラがその解決を行う必要があるのは勘弁。

＞What is “itself”
理解が正しければ、Zig コンパイラはプロジェクトのビルドファイルのローカルディレクトリにサンドボックス化されてる。C ヘッダーはおそらく例外だけどね。
ビルダーとリンカーはもう少し範囲が広い。

”ビルド時” には、デフォルト言語のビルドツールである Zig プログラムは、どこにでも、どこまでもアクセスできるんだ。Zig プロジェクトをビルドするには、Zig プログラムを使って依存関係を作成し、コンパイラを呼び出し、結果をキャッシュし、出力バイナリを作成し、リンクする必要がある。
comptime と build time を区別するのは、象牙の塔からの区別だよ。‘zig build’ はどこにでもアクセスして、何でも生成できるんだ。

それは単なる学術的なことじゃないんだ。コード内でパス外のものを @include しようとすると、嫌な思いをするだろうね。それに、‘zig build’ は Zig スイートの唯一のツールではなくて、個別のコンパイルコマンドもあるんだ。だから、これには実際的な意味があるんだよ。
git ツリー/サブモジュールシステムの外のものが実行内容に影響を与える可能性があるかどうかを確認するために、ワンストップで確認できる場所があるのは、コード/セキュリティレビューにも役立つんだ。

＞個人的には、コンパイラが完全に自分自身から外にアクセスできるなんて考えはマジで恐ろしい（ネットワークやデータベースにアクセス？マジかよ？）。”
コンパイラ自体ではないんだよ。
コードを生成できるビルドシステムが欲しいとしよう。それはすごく一般的で、おかしいことじゃないって、みんな同意できるよね？
もし Zig コードを生成するコードも Zig で書かれていたら、すごくない？ コード生成コードが完全に無関係な言語で書かれるべき理由は何？ 開発者がコンパイル時のコード生成を行うために、まったく新しい言語を学ぶ必要がある理由は何？ そうだよ、Rust のマクロを睨んでるんだ！

＞個人的には、コンパイラが完全に自分自身から外にアクセスできるなんて考えはマジで恐ろしい（ネットワークやデータベースにアクセス？マジかよ？）。”
なんでそう思うの？ F# には TypeProviders っていう機能があって、コンパイラに型を発行できるんだ。例えば、こんなことができる。
type DbSchema = PostgresTypeProvider<”postgresql://postgres:…”>
type WikipediaArticle = WikipediaTypeProvider<”https://wikipedia.org/wiki/Hello”>
これで、その Article や DB を参照する型ができた。手動で書いた型のように扱うことができるんだ。IDE、デバッガー、ロガーで完全に検査できる。一時ディレクトリに自動生成される完全な型なんだ。
最初見たときは、すごく奇妙だと思った。少し考えて、触ってみて、素晴らしいと思った。文字通り、史上最高のアイデアの 1 つだよ。ファーストクラスのコード生成フレームワークだ。いくつかの制限はあったけどね。
実際のプロジェクトで使ってみると、なぜ普及しなかったのかがわかる。すごく惜しいんだけど、何かが足りないんだ。たった 1 つだけ、ずれているんだ。CsvTypeProvider やパブリックなインターネット URL のようなファイルソースでないものの場合、インタラクションが苦痛なんだ。また、ソース管理や再現ができない依存関係がコードにできてしまう。ハックや回避策はあったけど、しっくりくるものはなかった。
しかし、Python や JavaScript のスクリプト構文を模倣しようとする静的型付け言語としては、最高の試みだったよ。DB URI を指定すれば、型を想定して使えるんだ。

＞個人的には、コンパイラが完全に自分自身から外にアクセスできるなんて考えはマジで恐ろしい（ネットワークやデータベースにアクセス？マジかよ？）。”
ゲーム開発では、コードは最終製品のほんの一部にすぎないんだ。”データ駆動” っていう言葉で調べるといいよ。ビルドの一部として、データとコードを部分的に評価する最適化パスを実行するのは普通のことなんだ。コードには、データの変更をサポートする ‘開発バージョン’ と、データが既知であることを前提とできる ‘出荷バージョン’ がある。
より伝統的な PGO+LTO の例は、コードが既存のデータに対してどのように特化できるかの別の例にすぎない。ビルド間で PGO プロファイリングデータが変更された場合、結果のバイナリに大幅な変更なしで対応できるツールチェーンは知らないな。

PGOデータって、コンパイラに食わせる静的ファイルじゃないの？それならコンパイラは決定的なんじゃない？

個人的には、コンパイラが外部にアクセスできるって考えはマジで怖いんだけど（ネットワークとかデータベースとかありえないっしょ？）。
＞まあ、build.rsとかMakefileで呼ぶやつもそうだけどね。cargoみたいなのがサンドボックス機能持ってたら面白いかも。

cargoはサンドボックスで実行できるよ。

そうなんだよね。でもcargoにやってほしいんだよね。build.rsが変なことしてたら教えてほしいし。

＞それってビルドシステムの仕事じゃん？
ビルドシステムとコンパイラの主な違いって何？コンパイラがビルドのやり方を知ってれば、コンパイル時のコード生成もコンパイル中にできるんじゃない？

個人的には、ビルドシステムとかいうものが必要なこと自体がマジで無理。

コンパイラにIOを求めてるわけじゃなくて、他の言語がマクロでできること（コマンド実行、コード生成、コードの読み書き、コードの変更）を求めてるんだよ。それはすごく便利だって証明されてる。

それ便利って言うけど、マジで？マクロはパワフルだと思うけど。
マクロはどの言語でもデバッグが地獄。comptimeならランタイムで実行できるからデバッグしやすい（型を返すのは例外）。マクロは認知負荷が高いし、衛生的なマクロを作るのは大変。Rustのproc-macrosとかどれだけクレート引っ張ってくるの？
マクロのフルパワーは、それによって生じる苦労に見合うかどうか疑問。

＞マクロはどの言語でもデバッグが地獄だって？
Common Lispでしかマクロ使ったことないけど、少なくともCommon Lispでは普通に関数みたいに開発してデバッグできるよ。macroexpandでマクロの出力を見れるし、エラーがあれば他の関数と同じデバッガーに飛ばされるし。

デバッグのためにREPLを使うってことは、インタラクティブな環境と、それに伴うオーバーヘッド（ヒープアロケーション、ガベージコレクション、tty、インタラクティブプロンプト、macroexpandのオーバーヘッドなど）があるってことだよね。
少なくとも、C、C++、Rust、Zigみたいな言語が想定してるシステムプログラミングの範囲外だよね。

build-timeのコード生成の方が、run-timeのJVM bytecode patchingより全然好きだな。JavaでORM使うのは魔法みたいで、何が動くか全然わかんないし。コード生成ありのORMの方がずっと良い。IDEで各関数が何してるか見れるし、デバッグもできるし。

コード生成に文句言ってるけど…それってzig固有の問題じゃないよね？zigのcomptimeに何か足りないせいでこうなってるって言うけど…何が？それに、zigでfree-formのコード生成がどれくらい使われてるか疑問。

俺はこれ、むしろ良い機能だと思う。C#だとMSBuildのpropsとかtargetいじらないといけないけど、あれマジで優しくないし。それに、この手のサポートがあるからこそJSは特別だし、JSのエコシステムは革新的なんだよ。

XS(たぶんSwig使う？)を学ぶのは、Perlをちゃんと理解するのにめっちゃ良い方法だった。

zigのコミュニティはコンパイル速度を気にしてるんだよ。制限なしのcomptimeはマジでヤバいことになる。

それってマジで的外れだと思う。
@setEvalBranchQuotaで好きなだけ大きくできるし、XMLファイルを@embedFileして、comptimeでパースして、それに基づいて型を生成できる(BTDT)。コンパイルを遅くしようと思えばいくらでもできる。
comptimeの表現力を制限することとコンパイル時間は関係ない。andrewrkのビジョンと違うuse-caseがあっても良くない？

OdinとかGoとかJaiとか、他のコミュニティと似たようなとこ多いよね。
なんか、昔に戻ろうぜ！みたいなノリなのがよくわからん。
皮肉なことに、最終的にはLLMが直接バイナリを生成するようになるから、こんなのどうでもよくなる。

スペイン語の、北欧神話の神についての引用はホルヘ・ルイス・ボルヘスの物語から。英語訳はここにあるよ:
https://biblioklept.org/2019/04/02/the-disk-a-very-short-sto…

もしあなたがその物語を読んで、私のように、投稿のトップにある引用が物語のどの部分なのかまだ疑問に思っているなら：
”それはオーディンの円盤だ。片面しかない。地球上には他に片面しかないものはない”

メビウスの輪がそうじゃん！

紙でできたメビウスの輪には表と裏の2つの面があって、さらに端っこもあるんだよね。

クラインの壺みたいな端がないものもあるけど、メビウスの輪と違って地球上には存在できないから、記事の引用は正しいことになるのかな？

スペイン語だとこれ：
https://www.poeticous.com/borges/el-disco?locale=es
スペイン語がよく分からなくて最初は「オーディンのディスコ」かと思ったけど、意味が通じないから「レコードのことかな」って思った。

オーディンのレコードにB面はないんだって。なぜならオーディンが書くものは全部最高だから。

昔はA面とB面があって、ビッグアーティストは両方の曲を宣伝する“Double A”を出すのが普通だったんだ。例えば、Nirvanaの“All Apologies”と“Rape Me”、The Beatlesの“Penny Lane”と“Strawberry Fields Forever”とか。

物語は短いけど強烈。オーディンは自分が持つ限り王でいられるという神秘的な円盤を明らかにする。それまで彼を受け入れていたキリスト教の隠者は、彼を崇拝せずキリストを崇拝すると言い、金のために円盤を奪って殺してしまう。彼はオーディンの体を川に捨て、円盤を見つけることはなかった。彼はオーディンが円盤を渡さなかったことを恨んでいた。現代のアメリカ人読者として、もし私がこの物語が現代のものだと信じたなら、キリスト教が名誉を破壊的な貪欲に置き換えているのだと思うだろう。オーディンの狼の子孫がヘブライ人を崇拝し、金のために彼を殺すのは悲しいことだが、それは不正確な人物描写ではないと思う。金銭的な祝福を渡さないことに対するオーディンへの恨みもある。それも私には悲しい。いつかオーディンがそのような軽蔑を受けないことを願っている。

Zigには部分評価/特殊化っていう別の機能があって、動的なコード生成のほとんどのユースケースをカバーできるんだよね。こういう洞察がZigの好きなところ。Andrew KelleyはKISS原則の守護聖人かも。昔、F#でマクロを使って賢いことをしようとしたら、もっと基本的な部分適用とか高階関数で実装できることに気づいたんだ。しかもコンパイラが最適化してくれるからパフォーマンスも問題ない。

Juliaコミュニティでも、メタプログラミングを最初の解決策として使うべきではないって議論されてるよ。多重ディスパッチとか高階関数の方がクリーンで速いからね。
https://discourse.julialang.org/t/how-to-warn-new-users-away…

comptimeの面白いところは、作業中に柔軟に対応できるところだよね。型情報が必要になったら、関数のパラメータに追加するだけ。それがどんどん伝播して完了する。あるいは、特定の状況では型を提供できないことに気づき、アーキテクチャや設計の問題を解決する必要が出てくる。

引数として渡す型が別の引数の型と同じ場合、関数内で@TypeOf(arg)を使うだけでAPIをシンプルにできるよ。

＞コンパイル時にコードを実行する時、どのマシンで実行されると思う？普通は自分のマシンって答えるよね。でも違うんだって！
これマジわかんねー。
クロスコンパイルしてる時って、comptimeのコードはホストマシンで実行されるんじゃないの？それってコンパイル時の定義じゃん？
エンディアンが変わるなら、Zigがターゲットマシンをエミュレートするってのはわかるけど。
なんか変な感じ。HostPlatformとTargetPlatformが違うのは良いんだけど、ホストプラットフォーム隠す意味がわからん。なんで隠したいんだろ？
誤解しないで欲しいんだけど、クロスコンパイルはマジで賛成派。Zigは他の言語よりマジで優秀だと思う。だから何がわかってないんだろ？
あ、待って。Jaiと違って、Zigのcomptimeはコンパイル時に実行されるわけじゃなくて、コンパイル時に既知のことだけを参照するってこと？いや、それも違うか。マジで混乱してきた。