型の流れは、私が頭の中で想像する型情報の流れとちょうど一致しています
number
を返すと推測されます。foo
はAdder
で、number
はa
と b
の型になります。argument -> parameter
は単に変数代入の一種です。foo
の型は{a:number, b:number}
と推論されます。a
/b
のメンバに分解します。foo
の型を知らないので、a
やb
の型を推論することはできません。foo
に型を指定された場合、関数パラメータの型を推論することができます(以下の例ではa
、b
は両方ともnumber
型であると推測されます)。foo
はany
の戻り値の型を持っています。addOne
の型定義が悪いため、fooの戻り値の型が影響を受けたものです(a
はany
なのでaddOne
の戻り値はany
で、foo
の戻り値はany
)。関数の返り値を明示するのが最も簡単だと分かります。結局のところ、これらのアノテーションは定理であり、関数本体が証明です。
noImplicitAny
noImplicitAny
は、変数の型を推測できない場合(したがって、暗黙のany
型としてしか持つことができない場合)、エラーを発生させるようにコンパイラに指示します。それによって、次のことが可能です。:any
型の注釈を加えることでany
型にしたい