Visitする前にresolveする

[sidepelican]

SType がその内部状態によって、一部の操作で結果が変化することがある。
hasTranspiledJSONType や generateDecodeFunction などが該当する。

let foo: SType =  ... // unresolved

generator.hasTranspiledJSONType(type: foo) // false
generator.hasTranspiledJSONType(type: try foo.resolved()) // true

SType の詳細に基づいて何かを出力する関数は、resolveに失敗したときはエラーがthrowされると嬉しいと思いました。少なくとも結果を区別できるようにしたいです。（ 例えば hasTranspiledJSONType の場合は、JSON型を持たないのか、そもそもunresolvedだから解決できないのか ）

[omochi]

resolveできていない型というのは、Swiftにおいてどんな型なのか定義が見えていない状態を意味しています。
現状では、C2TSの利用状況がハッキリと想定しきれていなかったので、
そのような場合もあってよいかと考えていました。
そこでとりあえず、unresolvedな型は、C2TSにおいては、デコーダ関数をもたない型という事になっています。

unresolvedな型があったら例外が飛ぶようにした場合、
コード生成をしようとしたときに、そのような型に出会うとコード生成が中断してしまいます。
例えば、ジェネリック型の型パラメータ部分の奥底や、
struct型のプロパティの奥底に、そういった型が潜んでいる可能性があります。

ユーザーとしては、そのような例外が飛ばないように、
その型が書かれた元ソースも SwiftTypeReader.Modules に読み込ませておくか、
その型について TypeMap のエントリを提供する必要が生じます。

まあ確かに、unresolvedな型については、
デコーダをもたない型として良い保証は全くないので、
TypeMapを提供する事を必須とする仕様変更は正しい方向に思います。

---

関連して、 TypeMapは今の所 TS側の型名の設定しかできませんが、
JSON型とdecode関数の名前、およびジェネリックシグネチャについても登録できるようにするのが正しいと思っています。
必要となる状況が限定されてるので後回しにしています。

---

ところで、 SType が、 resolve可能だけど resolveしていない状態に、遭遇したのでしょうか？
型宣言を取り込む場合は最初からresolveされているのと、
stored propertyやgeneric argumentsから STypeを取り出すときには、
そこでresolveが呼びされてるようになっているので、
基本的には SwiftTypeReader のユーザー側から触ろうとするときには、
一度はresolveが試みられたSTypeが返ってくるようになっている想定ではあります。

まあ、このresolveを隠蔽する設計は良くないので、
Type、Type Declaration, Type Representationを分離する改修は将来的にやりたいなと思っています。

[sidepelican]

SType が、 resolve可能だけど resolveしていない状態に、遭遇した

シチュエーションとしてはこの場所になります
https://github.com/sidepelican/CallableKit/blob/d52f87945336cfd07bb22d9839f17ca741df6598/Sources/Codegen/ServiceProtocolScanner.swift#L56

[sidepelican]

resolvedされたSTypeから元の記述の通りの型名を取り出せないので、unresolvedTypeから型名を取り出すというややハッキーな操作ではありますね。

例としては A モジュールに A.Foo.Request という完全な型名を持つSTypeが存在した時に、コード生成側が使いたい型名は Foo.Request であって、A.Foo.Request でも Request でもない、というケースですね。参照元コードに記載されていたままの省略度の型名が欲しい。

[omochi]

なるほど。

元々の表記を参照したいから明示的に unresolved type を利用する一方で、
c2tsの操作もしたいからresolved typeが必要になるが、
混ざってしまうと意図しない不具合に繋がるので、resolve忘れを検出したいわけですね。

c2tsがunresolvedな型に対する問い合わせを例外で返すのが良さそうですね。

---

ちなみに、 Foo.Request に関しては、
SType.toSpecifier() から A.Foo.Request が取得でき、
それを TypeSpecifier.removeModuleElement で Foo.Request に変形可能です。

ただ、元表記が Foo.Request だった場合と、 Request だった場合で、
どちらの場合も元表記を再利用したい場合は、
実例のように 元々の TypeSpecifier を直接利用してもらうしかないですね。

---

この、「コードで書かれた型の表記と、解決された型情報を両方取り回したい」
という要求はSwift Compiler内部でも工夫して実現されています。

実際、初期のSwiftコンパイラは、typealiasを使っている場合に、
エラーメッセージではaliasの右側が使用されているのでわかりづらい、
という問題がありました。

typealias以外にも、 Foo? などの suger type (正規形は Optional<Foo>) も、
この問題に含まれます。
これを参考に、resolved typeが元表記も扱えるのが理想ですが、
詳しくは理解してないのですぐには難しいです。

[omochi]

1.8.0 で対応したので試してみてください。
https://github.com/omochi/CodableToTypeScript/releases/tag/1.8.0

[sidepelican]

エラーが出て区別可能になりました。ありがとうございます