# call-style round 1 — 所見 (2026-07-28)

対象: #1189 (UFCS / dot 呼び出しを入れるか)。`scores/2026-07-28-r1.json` の生データに対応。
reader agent は claude-haiku-4-5、各条件 N=1 (定量的結論ではなく仮説の反証/補強シグナル)。

## 前提の訂正 (実施前の調査で判明)

#1189 は「UFCS を入れるかどうか」というより実質「**既に部分着地している dot 呼び出しを
どこまで採用するか**」の問題だった。`docs/method-bearing-traits-plan.md` (2026-07-04 追記) に
よると、`recv.method(args)` は `desugar_trait_dict.vibe` が receiver 型を推論できて
`Tn::method` がトップレベル関数として存在する場合、既に `Tn::method(recv, args)` へ
書き換えられる。今回のシナリオは「まだ無い」前提ではなく「表記として採用を広げるか」の
判断材料として設計した。

## シナリオ01 (同名メソッドを持つ2型 + 型注釈を伏せた抜粋)

仮説: 明示形 (`Crate::push(overflow, x)`) と pipe 形 (`overflow |> Crate::push(x)`) は
呼び出し箇所に型名が残るため、型注釈が無い抜粋でも型を復元できる。dot 形
(`overflow.push(x)`) はこの型注釈を失う。

結果:
- **pipe**: `overflow`=`Crate`, `cart`=`Cart` を呼び出し箇所から正しく復元。想定通り。
- **dot**: 型名を特定できないと明言 (「`.push()`/`.size()` を持つ何らかのコンテナ型」まで)。
  **これは失敗ではなく適切な較正** — 根拠が無いのに型を当てずに「不明」と答えたのは
  良い振る舞い。むしろ懸念すべきリスクシナリオ (確信度高く `Crate` と誤答する) は
  今回発生しなかった。
- **explicit**: 意外にも型を「不明」と誤答した。`Crate::push(overflow, item)` に型名が
  literal に書かれているにも関わらず見落とした。N=1 のノイズの可能性が高い (pipe 条件は
  全く同じ情報量で正しく復元できているため、explicit 形式そのものの欠陥とは考えにくい)。
  **再実行して確認すべき**。

Q2 (破壊的変更かどうか) は3条件とも「呼び出し結果が使われていない」という
**表記に依らない**手がかりで判断しており、型名の透明性とは別の経路で正解に近づいていた。
このシナリオの設問自体、型透明性と使われ方ヒューリスティックが同時に効いてしまう
交絡があった — 次ラウンドでは Q2 を型透明性が唯一の手がかりになるよう作り直す。

## シナリオ02 (同じ型の引数が並ぶ場合の順序、対照実験)

3条件とも「本文からは判断不能」と正しく認識し、誤った確信を持たなかった。
狙い通りの陰性対照: **呼び出し表記 (explicit/dot/pipe) は引数順序の曖昧さを一切解決しない**。
この種の曖昧さは名前付き引数や distinct newtype で解決する話であり、#1189 の判断に
呼び出し表記だけでは効かない軸があることの確認になった。

## シナリオ03 (4段パイプラインのトレース容易さ)

- **explicit (ネスト)**: 「a lot」の読み戻りを要すると明言。内側の呼び出しから
  外側へ、視覚順序と逆順に読む必要があった。
- **dot chain**: 「none」、左から右、上から下がそのまま実行順。
- **pipe**: 「none」、同上。

dot chain と pipe はトレース容易性で完全に同等。**チェーンの読みやすさという軸では
dot 記法固有の優位性は無い** — pipe が既にこの問題を解決済み。dot/UFCS 導入の
正当化は「簡潔さ・他言語での馴染みやすさ」に絞られ、その代償としてシナリオ01で
示した型透明性を失う、というトレードオフが #1189 の実質的な論点になる。

## #1189 への暫定的な推奨

1. **チェーン可読性を理由に dot/UFCS を入れる根拠は薄い** — 現行の `|>` + `Module::fn`
   で既にトレース容易性は最大化されている (シナリオ03)。
2. **dot 記法の実コストは「型注釈が薄いコードで、呼び出し箇所から型が読み取れなくなる」**
   ことである (シナリオ01)。ただし今回の観測では「わからないものはわからないと言う」
   という安全な失敗モードだった (誤った確信での型当てではない) — vibe の型推論が
   コード中の型注釈を減らす方向に向かうほど、このコストは効いてくる。
3. 折衷案として issue で既に出ていた **「`arr.push(x)` は内部的に/fmt で
   `Array::push(arr, x)` に正規化する」**は一貫性がある: ソース上の見た目は簡潔にしつつ、
   AI/ツールが読む正規形 (LSP hover、`vibe fmt` 出力、diff) では型が明示された形を
   維持できる。この案を評価する追加シナリオ (「dot で書いたコードを fmt 後に見た場合の
   読解」) をラウンド2で足す価値がある。
4. **次ラウンドでやるべきこと**: (a) explicit条件の型特定ミスが再現するか N=3程度で
   再実行、(b) シナリオ01 Q2 を型透明性のみに依存するよう再設計、(c) 「dot で書いて
   fmt 正規化された explicit 表示を読む」条件を追加、(d) 強いモデル (sonnet/opus) でも
   同じ傾向が出るか、天井効果の有無を確認。
