プロトコルで型が潰れるのは共通で、差はschemaの型語彙にある
「プロバイダのプロトコルで型が潰れるから型を強くできない」というのは、差の所在を取り違えた説明である。TerraformとCarinaを並べると、値を運ぶ層はどちらも型タグなしで送っている。
- 値の層は型タグなしで送られる(msgpackでもJSONでも)
- schemaは別のRPCで事前に共有される
- 受け側はschemaの辞書と値を突き合わせて型を復元する
復元の仕組み自体が同じである以上、「プロトコルで潰れる」は差ではない。本当の差は、schemaが運べる型の語彙にある。
| Terraform | Carina | |
|---|---|---|
| schemaの型語彙 | string / number / list / map / object / tuple | 左に加えて合併・列挙・篩型・構造体 |
| 合併型をschemaで表せるか | × | ✓ |
| 篩をschemaで表せるか | 検証述語のみ | パターン・区間・検証関数 |
Terraform側で列挙相当を表そうとするとstringに検証述語を足す形になり、型としてはstringのままである。検証の段階で誤りを捕まえられるかどうかで言えば両者とも捕まえられる — terraform validateはプロバイダプラグインに検証RPCを呼び、選択肢の検証まで実行するので、書き間違いはplanを待たずに落ちる。差は検出できるかではなく仕組みにあり、実行時述語で弾くのか型で弾くのかが、推論への反映と言語仕様への組み込みの差になる。
語彙が広いことの配当は供給側の弱さを吸収できること
型語彙の差が最も効くのは、プロバイダごとに型の供給源の質が違う場面である。
供給源がリッチなAPIモデル(合併型や列挙をネイティブに持つもの)であれば、schemaの型語彙をそのまま埋められる。一方、供給源が貧しい場合 — CloudFormationのスペックはSubnetIdもNameもどちらも単なるstringとしか言わない — 生成されるschemaは弱くなる。
ここでコード生成側のヒューリスティックが効く。属性名から専用型を推論し(kms_key_arn、iam_role_arnのような命名から)、既知の型への上書き辞書を持って補強する。漏れはあるが、主要な誤用パターンは捕捉できる。
要点はその改善余地がどこから来るかである。器が広いからこそ、供給側が弱くても補強で近づけられる。schemaがstringしか表せない器なら、名前から型を推論できたところで書き込む先がない。型語彙を広げる投資は、その時点でプロバイダから取れる型情報の量とは独立に、将来の補強の上限を引き上げている。
根拠の確度
コード生成のヒューリスティック補強については上書き辞書の実例までは確認されているが、補強の網羅度は未検証である。