Typescript: Facebookフロー型システムとの比較

これは興味深いものであり、さらに議論するための良い出発点です。 わかりやすくするために、元の投稿にコピー編集の変更を加えてもよろしいですか？

フロー内の予期しないもの（詳細を調査するときにこのコメントを更新します）

奇関数の引数型推論：

/** Inference of argument typing doesn't seem
    to continue structurally? **/
function fn1(x) { return x * 4; }
fn1('hi'); // Error, expected
fn1(42); // OK

function fn2(x) { return x.length * 4; }
fn2('hi'); // OK
fn2({length: 3}); // OK
fn2({length: 'foo'}); // No error (??)
fn2(42); // Causes error to be reported at function definition, not call (??)

オブジェクトリテラルからの型推論はありません：

var a = { x: 4, y: 2 };
// No error (??)
if(a.z.w) { }

これは興味深いものであり、さらに議論するための良い出発点です。 わかりやすくするために、元の投稿にコピー編集の変更を加えてもよろしいですか？

私が言ったように、目的はフロータイプシステムに投資して、いくつかの機能がTypeScriptシステムに適合するかどうかを確認することです。

@RyanCavanaugh最後の例だと思います：

var a = { x: 4, y: 2 };
// No error (??)
if(a.z.w) { }

ヌルチェックアルゴリズムに関連するバグです。報告します。

です

type A = () => void & (t: string) => void
var func : A;

に相当

Declare A : () => void | (t: string) => void
var func : A;

それともそうかもしれませんか？

@ Davidhanson90実際にはそうではありません：

declare var func: ((t: number) => void) | ((t: string) => void)

func(3); //error
func('hello'); //error

この例では、フローは共用体タイプfuncのどのタイプであるかを知ることができないため、どちらの場合もエラーを報告します。

declare var func: ((t: number) => void) & ((t: string) => void)

func(3); //no error
func('hello'); //no error

funcには両方のタイプがあるため、両方の呼び出しが有効です。

TypeScriptの{} mixedとFlowの

@RyanCavanaugh考えた後、私は本当にわかりません。それはまだそれについて考えているのとほとんど同じだと思います。

mixedはプロパティがなく、 {}が持っているObject.prototypeから継承されたプロパティもありません（＃1108）これは間違っています。

もう1つの違いは、Flowが型推論を逆方向に伝搬して、推論された型を型共用体に拡張することです。 この例はhttps://github.com/facebook/flow/issues/67#issuecomment-64221511からのものです

class A { x: string; }
class B extends A { y: number; }
class C extends A { z: number; }

function foo() {
    var a = new B();
    if (true) a = new C(); // TypeScript reports an error, because a's type is already too narrow
    a.x; // Flow reports no error, because a's type is correctly inferred to be B | C
}

（「正しく」は元の投稿からのものです。）

これは、以下もコンパイルされることを意味します。

var x = "5"; // x is inferred as string
if ( true) { x = 5; } // Inferred type is updated to string | number
x.toString(); // Compiles
x += 5; // Compiles. Addition is defined for both string and number after all, although the result is very different

編集：2番目のスニペットをテストしましたが、実際にコンパイルされます。
編集2：以下の@fdecampredonで指摘されてif (true) { }は、フローにタイプをstring | numberとして推測させる必要があります。 if (true)がないと、代わりにnumberとして推測されます。

あなたはこの行動が好きですか？ 共用体のタイプについて話し合ったときにこのルートをたどりましたが、その価値は疑わしいものです。 型システムが複数の可能な状態を持つ型をモデル化できるようになったからといって、それらをどこでも使用することが望ましいとは限りません。 表面上、静的型チェッカーを備えた言語を使用することを選択したのは、型注釈を書くのが好きだからという理由だけでなく、間違いを犯したときにコンパイラーエラーが必要だからです;）つまり、ほとんどの言語はこのような例でエラーを出します（特に2つ目は、型空間をモデル化する方法がないためではなく、これがコーディングエラーであると実際に信じているためです（同様の理由で、多くの暗黙のキャスト/変換操作をサポートすることを避けています）。

同じ論理で、私はこの振る舞いを期待します：

declare function foo<T>(x:T, y: T): T;
var r = foo(1, "a"); // no problem, T is just string|number

しかし、私は本当にその振る舞いを望んでいません。

@danquirkエラーを報告する代わりに自動的に共用体型を推測することは、私が好む動作ではないことに同意します。
しかし、それは実際の言語ではなく、フローの哲学に由来すると思います。フローチームは、単純に型チェッカーを作成しようとします。最終的な目標は、型の注釈なしで「より安全な」コードを作成できるようにすることです。 これにより、厳格さが緩和されます。

この種の行動の影響をノックすることを考えると、正確な厳密さは議論の余地があります。 多くの場合、エラーを延期する（またはエラーを完全に非表示にする）だけです。 型引数の古い型推論規則は、同様の哲学を非常に反映しています。 疑わしい場合は、タイプパラメータをエラーにするのではなく{}と推測しました。 これは、いくつかの間抜けなことを実行しても、結果に対して安全にいくつかの最小限の動作セットを実行できることを意味しました（つまり、 toStringようなもの）。 一部の人々がJSで間抜けなことをするという理論的根拠は、私たちができることを許可するように努めるべきです。 しかし実際には、{}の推論の大部分は実際には単なるエラーであり、 T型の変数を最初に点在させて、{}（または同様に予期しない共用体型）であることに気付くまで待たせましたそして、後方へのトレースはせいぜい迷惑でした。 ドットを付けたことがない（またはタイプTの何かを返さなかった）場合は、実行時に何かが爆発した（またはさらに悪いことにデータが破損した）まで、エラーにまったく気づきませんでした。 同様に：

declare function foo(arg: number);
var x = "5";
x = 5;
foo(x); // error

ここでのエラーは何ですか？ 本当にxをfoo渡すのですか？ それとも、初期化されたものとは完全に異なるタイプの値をxに再割り当てしたのでしょうか。 人々が本当に意図的にその種の再初期化を行うのに対して、誤って何かを踏みつけるのはどれくらいの頻度ですか？ いずれにせよ、 x共用体型を推測することで、それでも（より悪い）エラーが発生する場合、型システムは全体的にそれほど厳密ではなかったと本当に言えますか？ この種の推論は、結果の型で特に意味のあることを何もしない場合にのみ、それほど厳密ではなくなります。これは一般的に非常にまれです。

ほぼ間違いなく、 nullとundefinedを任意の型に割り当て可能なままにしておくと、同じ方法でエラーが非表示になります。ほとんどの場合、ある型で型指定され、 null値を非表示にすると、実行時のエラー。

Flowのマーケティングの重要でない部分は、TSがanyを推測する場所で、タイプチェッカーがコードをより理解するという事実に基づいています。 その哲学は、コンパイラに型を推測させるために注釈を追加する必要はないということです。 そのため、彼らの推論ダイヤルは、TypeScriptよりもはるかに寛容な設定になっています。

var x = new B(); x = new C(); （BとCの両方がAから派生している）がコンパイルされるべきであるという期待を誰かが持っているかどうかにかかっています。

1. コンパイルしないでください。
2. コンパイルして、BおよびC-Aの型階層に共通する最も派生した基本型として推測する必要があります。数値と文字列の例では、{}になります。
3. コンパイルしてB | Cとして推測する必要があります。

TSは現在（1）を実行し、Flowは（3）を実行します。 私は（3）よりも（1）と（2）の方がずっと好きです。

元の号に@Arnavionの例を追加したかったのですが、少し遊んだ後、私たちが理解しているものよりも奇妙なことがあることに気づきました。
この例では：

var x = "5"; // x is inferred as string
x = 5; // x is infered as number now
x.toString(); // Compiles, since number has a toString method
x += 5; // Compiles since x is a number
console.log(x.length) // error x is a number

今：

var x = '';
if (true) {
  x = 5;
}

この例の後、xはstring | number
そして私がそうするなら：

1. var x = ''; 
2. if (true) {
3.  x = 5;
4. }
5. x*=5;

1行目で次のようなエラーが発生しました： myFile.js line 1 string this type is incompatible with myFile.js line 5 number

私はまだここで論理を理解する必要があります...。

私が忘れていた流れについての興味深い点もあります：

function test(t: Object) { }

test('string'); //error

基本的に「オブジェクト」は他のプリミティブ型と互換性がないので、意味があると思います。

「汎用解像度キャプチャ」は、TSにとって間違いなく必須の機能です。

@fdecampredonはい、その通りです。 var x = "5"; x = 5; xの推定タイプはnumber更新されます。 2番目の割り当ての周りにif (true) { }追加すると、タイプチェッカーはだまされてどちらかの割り当てが有効であると想定します。そのため、推測される型は代わりにnumber | stringに更新されます。

number | stringは*演算子をサポートしていないため、 myFile.js line 1 string this type is incompatible with myFile.js line 5 number発生するエラーは正しいです（共用体タイプで許可される操作は、すべてのタイプのすべての操作の共通部分のみです。連合）。 これを確認するには、 x += 5変更すると、コンパイルされます。

コメントの例を更新して、 if (true)

「汎用解像度キャプチャ」は、TSにとって間違いなく必須の機能です。

+1

@Arnavion 、 B | Cよりも{}を好む理由がわかりません。 B | Cを推測すると、型システムの一般的に望ましいプロパティであるafaikの正確性を損なうことなく、型チェックを行うプログラムのセットが広がります。

例

declare function foo<T>(x:T, y: T): T;
var r = foo(1, "a"); // no problem, T is just string|number

すでにTを除く現在のコンパイラの下typechecksは、と推定される{}ではなくstring | number 。 これは正確さを損なうものではありませんが、大まかに言えばあまり役に立ちません。

Infering number | stringの代わりに{}私には問題ないようです。 その特定のケースでは、有効なプログラムのセットが拡張されませんが、型が構造を共有している場合、型システムはそれを認識し、いくつかの追加のメソッドやプロパティを有効にすることは改善のように思えます。

B | C推測すると、正確性を損なうことなくタイプチェックするプログラムのセットが広がります

文字列または数値のいずれかで+操作を許可すると、操作がまったく類似していないため、正確性が損なわれると思います。 操作が共通の基本クラス（私のオプション2）に属している状況とは異なります。その場合、ある程度の類似性が期待できます。

+演算子は、互換性のない2つのオーバーロードがあるため呼び出しできません。1つは両方の引数が数値で、もう1つは両方が文字列です。 B以来| Cは文字列と数値の両方よりも狭いため、どちらのオーバーロードでも引数として使用できません。

関数が引数に対して二変量である場合を除いて、それは問題になる可能性がありますか？

var foo: string; console.log(foo + 5); console.log(foo + document);コンパイルされるので、文字列+演算子は右側で何でも許可するので、 string | numberは有効な操作として+ <number>を持つことになります。 しかし、あなたは正しいです：

error TS2365: Operator '+' cannot be applied to types 'string | number' and 'number'.

多くのコメントは、フロー内のタイプの自動拡張に焦点を当てています。 どちらの場合も、注釈を追加することで、必要な動作を実現できます。 TSでは、宣言で明示的に拡張します： var x: number|string = 5; 、フローでは、宣言で制限します： var x: number = 5; 。 型宣言を必要としないケースは、人々が最も頻繁に使用するケースだと思います。 私のプロジェクトでは、 var x = 5; x = 'five';は共用体型よりもエラーになることが多いと思います。 ですから、TSはこれについて正しい推論をしたと思います。

私が最も価値があると思うフロー機能については？

1. null以外のタイプ
   これはバグを減らす可能性が非常に高いと思います。 既存のTS定義との互換性のために、Flowのnull許容修飾子?stringではなく、null以外の修飾子string!として想像します。 これには3つの問題があります。
   クラスメンバーの初期化を処理する方法は？ _（おそらく、それらはctorで割り当てられる必要があり、割り当て前にctorをエスケープできる場合は、null許容と見なされます）_
   undefined処理方法
   明示的な型宣言がたくさんなくても機能しますか？
2. mixedとObject違い。
   C＃とは異なり、プリミティブ型はオブジェクトが使用できるすべての場所で使用できるわけではないためです。 ブラウザでObject.keys(3)を試してみると、エラーが発生します。 しかし、エッジケースは少ないと思うので、これは重要ではありません。
3. 一般的な解像度のキャプチャ
   この例は理にかなっています。 しかし、私はそれから恩恵を受けるであろう多くのコードを書いているとは言えません。 多分それはアンダースコアのような機能的なライブラリに役立つでしょうか？

自動共用体型推論について：「型推論」は型宣言に限定されていると思います。 省略された型宣言を暗黙的に推測するメカニズム。 Goの:=に。 私は型理論家ではありませんが、私が理解している限り、型推論は、割り当て元の式の型から推測される、すべての暗黙的な変数宣言（または関数の引数）に明示的な型注釈を追加するコンパイラパスです。 私の知る限り、これはそれがどのように機能するかです..まあ..そこにある他のすべての型推論メカニズム。 C＃、Haskell、Go、これらはすべてこのように機能します。 か否か？

実際のJSにTSセマンティクスを指示させることについての議論は理解していますが、代わりに、これは他の言語に従うのにおそらく良い点です。 結局のところ、タイプはJSとTSの唯一の明確な違いです。

私はFluxのアイデアがたくさん好きですが、これが実際にこのように行われた場合、これは奇妙なことです。

null以外の型は、最新の型システムの必須機能のようです。 tsに追加するのは簡単でしょうか？

ヌル不可能な型をTSに追加することの複雑さについて少し読みたい場合は、 https：//github.com/Microsoft/TypeScript/issues/185を参照して

言うまでもなく、null許容型ではないのと同じくらい素晴らしいのは、今日の人気のある言語の大部分には、デフォルトでnull許容型（機能が真に優れているところ）や一般化されたnull許容型機能がまったくないことです。 そして、複雑であり、非ヌル可能性の価値の多くがデフォルトであることにあるという事実のために、事後にそれを追加しようとした（または正常に追加した）人はほとんどいません（不変性と同様）。 これは、ここで可能性を考慮していないということではありませんが、必須の機能ともは言えません。

実際、null以外の型を見逃しているのと同じくらい、フローから見逃している本当の機能はジェネリックキャプチャです。tsがすべてのジェネリックを{}解決するという事実により、一部の機能構造、特にカリー化での使用が非常に困難になります。

個人的には、一般的なキャプチャと非ヌル可能性は、フローからの_高い_値のターゲットです。 他のスレッドを読みますが、ここにも2cを入れたかったのです。

非ヌル可能性を追加することの利点は、ほぼすべてのコストの価値があると感じることがあります。 これは非常に可能性の高いエラー状態であり、デフォルトのnull可能性があると、組み込みの値が弱まりますが、TypeScriptには、どこにでもあると単純に想定してnull可能性について議論する機能さえありません。

ハートビートでnull不可として検出できるすべての変数に注釈を付けます。

フローのサイトには文書化されていない、フローにはかなり多くの隠された機能があります。 SuperTypeバウンドタイプと実存タイプを含む

http://sitr.us/2015/05/31/advanced-features-in-flow.html