黙って捨てるのは、落とすことより悪い
k1LoW/deckはGoogle Slidesのプレースホルダが足りないとき、溢れた内容を黙って捨てる。エラーも警告も出ない。出力されたスライドを一枚ずつ見比べるまで、書いたはずの段落が消えていることに気付けない。
peithoはこれをビルドエラーに変えた。設計文書で「silent dropping is absolutely forbidden」と書かれ、実装規約としてパーサが未知の構造を _ => {} で飲み込むことを禁じている。
error: slide 4 needs 2 code slots but layout 'title-body-code' only allows up to 0..1
= help: use layout 'code-2col', or split the content across explicit slotsなぜ「捨てる」が特に悪いのか
失敗の悪さは損失の大きさでは決まらない。気付けるかどうかで決まる。
ビルドが止まる
損失は「その場で作業が止まる」こと。大きく見えるが、コストはその場で全部払い終わっている。
黙って捨てる
損失は段落1つ。小さいのに、いつ発覚するか分からない負債として残る。しかも発覚する場所は最悪の場所 — 聴衆の前だ。
これは「書いたのに効いていない」という失敗モードで、構造体の封印が未知フィールドを拒否する理由と同じものである。あちらは打ち間違いを構文の位置で捕まえ、こちらは溢れをビルドの位置で捕まえる。捕まえる場所は違うが、避けている失敗モードは同一である。
「余りが無いこと」の検査は独立の段
peithoの検査パスは4段あり、最後の1段が要点になっている。
- 内容の断片をスロットへ割り当てる
- 各スロットの中身が
accepts(型)を満たすか arity(個数)を満たすか- 割り当てられずに余った内容が無いか + 必須スロットが埋まっているか スロット側からは見えない。内容側から見る段としてしか書けない
1〜3は「スロット側から見た検査」で、これだけでは足りない。どのスロットも型と個数を満たしているのに、行き先の無い段落が余っている状態が通ってしまうからだ。余りの検査は、内容側から見る4段目としてしか書けない。
型検査を「宣言された穴が正しく埋まっているか」とだけ捉えると、この段は抜け落ちる。全域性(totality)を、入力の側からも要求していると読むのが正しい(静的段階の全域性は構文制限だけでは得られない)。