意外な落とし穴あるんだな
詳しくないけど、置換で置き換えができるならコンパイラが最適化してもいいのでは。即時評価を期待してるのに遅延評価になったらダメか。
“交差型 (&) が幾重にも重なった複雑な型定義では、この計算コストが指数関数的に増大し、型チェック全体のパフォーマンスを著しく低下させるのです。”
昔からこれあるよなあ typeで作られた型をextendしたインタフェース作って回避したりとかしてたわ
うーん不思議だ。単純な交差型なら計算量は線形に収まりそうなものだけど。ある日突然遅くなったなら、その間の変更をじっくり見たいところだ
へー。typeしか使ってないわ
なんかさ、typeで書いたほうがかっこいい感じするじゃん。なんとなく。（陥し穴に落ちるやつ）
原因の掘り下げしてなさすぎだろ。こんなにレベル低いのに結論とか書いちゃっていいのかな
なるほど
うーんあんまり納得できない
等価ならinterfaceの方が良いけど緩いinterfaceで複雑な条件分岐するなら厳密なtype使ってtypegurdした方が実行環境では最適化し易いだろうし原因もわからぬまま状況証拠のみで”結論"とか"使うべき"って強い言葉は良くない
【結論】TypeScriptの型定義はtypeよりinterfaceを使うべき理由
意外な落とし穴あるんだな
詳しくないけど、置換で置き換えができるならコンパイラが最適化してもいいのでは。即時評価を期待してるのに遅延評価になったらダメか。
“交差型 (&) が幾重にも重なった複雑な型定義では、この計算コストが指数関数的に増大し、型チェック全体のパフォーマンスを著しく低下させるのです。”
昔からこれあるよなあ typeで作られた型をextendしたインタフェース作って回避したりとかしてたわ
うーん不思議だ。単純な交差型なら計算量は線形に収まりそうなものだけど。ある日突然遅くなったなら、その間の変更をじっくり見たいところだ
へー。typeしか使ってないわ
なんかさ、typeで書いたほうがかっこいい感じするじゃん。なんとなく。（陥し穴に落ちるやつ）
原因の掘り下げしてなさすぎだろ。こんなにレベル低いのに結論とか書いちゃっていいのかな
なるほど
うーんあんまり納得できない
等価ならinterfaceの方が良いけど緩いinterfaceで複雑な条件分岐するなら厳密なtype使ってtypegurdした方が実行環境では最適化し易いだろうし原因もわからぬまま状況証拠のみで”結論"とか"使うべき"って強い言葉は良くない