<p>TypeScript4.0反復計画</p>

おそらく実験的なフラグの後ろにある4.0にhttps://github.com/microsoft/TypeScript/pull/29818を含めることを検討しますか？

これは、ファクトリ関数の定義自体の変更によって複雑になります。

ただし、_separate_ファクトリ仮想型定義を導入することは興味深いかもしれません。 たとえば、 JSX.Factory 、またはReact.JSX.Factoryは、TypeScriptが推論に使用できます。 JSX文法を関数呼び出しに変換するだけで十分または効率的かどうかはわかりませんが、仮想型であるため、具体的なJavaScriptエンティティに対応する必要はありません。 もちろん、リスクは現在と同じ状況になりつつあり、多くの仮想型が、子だけでなく、React15以降に導入されたいくつかの機能の型安全性を制限することになりました。

4.0にもhttps://github.com/microsoft/TypeScript/pull/24738を含めることを検討しますか？

＃15230 [👍27]のようなチケットが「需要が高い」と見なされているのに、＃33038 [👍140とあなた自身の@weswighamによる実際のPR]または＃202 [👍390]の言及がないのは少し悲しいです。 「いいね」に基づいて実際に比較したり優先順位を付けたりすることはできないと思いますが、特に4.0がこのような機能を導入する良い機会のように思われるため、これらに関するロードマップの更新があれば素晴らしいと思います。 🙏

配列の破壊などに不正確な型指定が提供された、約200件のコメント＃13778でフィードバックを待っている約3。5年前の問題。 Pwettypwease修正を実装できますか🙏

ロードマップやイテレーション計画に注意が必要だと思われる問題をときどき後押ししてくれる人に感謝しますが、ここで明確にする必要があると思います。「需要の高いバグ修正を調査する」セクションは、明らかに多くの原因となっている問題を調査することによって決定されました。ペーパーカットですが、範囲は妥当と思われました。 私たちは、言及された問題にまだ注意を払っていますが、それらのいくつかは、範囲が限定されておらず、明確な理想的な結果をもたらしていません。

例：

• 名目上のブランドは素晴らしいでしょうが、それは名目上の将来の言語の方向性で構成されますか？ 私はそれを提案した人としてのプレースホルダータイプについてもこの懸念を持っています。
• インデックス署名のundefinedは興味深い例ですが、現在の仮定の下ですでに操作している人の90％が困難になるような動作を追加したくありません。 ユーザーがこれらのチェックを段階的に採用できるようにするアプローチを見つけることは、私たちにとって明らかなことではありません。 一連の条件付き型と特別なコンパイラチェックで技術的に可能であるとしても、それらのソリューションは非常に明らかにハッキーであり、すぐに機能しなくなる傾向があります。

名目上のブランドは素晴らしいでしょうが、それは名目上の将来の言語の方向性で構成されますか？

@DanielRosenwasserあなたのビジョンにおける将来の言語の方向性は何ですか？

私の心が名目上どこにあるのかについて、いくつかの文脈を説明すると思います。 記名的型について尋ねるときに人々が念頭に置いているさまざまなアイデアがたくさんあります。

• 「従来の」宣言ベースの名義（たとえば、ほとんどのOO言語で見られるもの）
• 不透明（OPAQUE）型（外部で内容が完全に不明な型）
• 個別のエイリアス（C / C ++ / C＃の単一メンバーstruct newtype 、Kotlinのインラインクラス）
• 測定単位（次元分析を言語にエンコードする方法）

これらのいくつかの間には陰影があり（たとえば、プレースホルダー型宣言-実装型にフォールバックする不透明（OPAQUE）型の一種の変形）、次にこれらのそれぞれをブレンドするさまざまな方向があります。

@RyanCavanaughは、3人の子供が両親にペットを求めているという、これについての素晴らしい例えを持っていました。 人は犬が欲しい、人は猫が欲しい、人は魚が欲しい。 彼らは両親に「いつペットを飼うのか！？」と尋ねます。 明らかに彼らは皆、ペットが欲しいことに同意していますが、それぞれが異なるペットを望んでいます！

ブランドタイプは好きですか？ そうです！ ブランドタイプは、個別のエイリアスのようなものを実現し、ほとんどのユーザーが探しているものに適合します。 しかし、それが正しい考え方だとは思いません。 多くの既知のトレードオフで具体化するためのより多くの設計スペースがあり、解決策をできるだけ早く急ぐ必要があるという感覚を私に与えるものは何もありません。

https://github.com/microsoft/TSJS-lib-generator/pull/858をTypeScript4.0に組み込むことができればと思います。

@DanielRosenwasserまず最初に記事をありがとう🙇

記名的型がTypeScriptで実際にどのようなユースケースに対応しているかについて少し詳しく説明していただけますか？

最初に：テキストまたはレポの巨大な壁に私を送ってください、そして私はそれを読みます：]

プレースホルダー型のような不透明（OPAQUE）型を意味するのではなく、「従来の」記名型と呼ばれるものを意味します。

記名的型はJavaScriptとは正反対だといつも感じていたので、以前の試みはあまりうまくいきませんでした。 それをかなりうまく機能させる方法があり（swiftのプロトコルとhaskellの型クラスは「名目だが外部から拡張可能」として頭に浮かぶ）、あなたは「確立された」方法のほとんどに精通していると確信しています（私は「測定単位」はF＃ウィンクであると想定します）。

私は多くの人々が名目上の（「伝統的な」タイプのように）タイプを求めているのを見つけましたが、_why_についての多くの記事はありません。

時間の経過とともに、「従来の」記名的型を要求する人はますます少なくなっています。これはおそらく、コミュニティが集合的に構造型のメンタルモードを構築しているためです。 タイプが実際に名目上機能する場所がいくつかあります（ instanceofが関係している場合、またはプライベートがある場合）。 その一部は、より優れた制御フロー分析と互換性チェックでキャプチャされますが、完全ではありません。

「従来の」ユースケースのいくつかは、オーバーヘッドがゼロの公称ラッパータイプ（例： newtype ）のユースケースと同じであり、多くの場合、ファイルなどの特別な処理を保証することを目的としています。パス、信頼できない文字列など。

Typescriptはすでに十分に表現力があると感じています。 私が個人的に見たいのは、より良いツールの統合です。

• ESMのサポートhttps://github.com/microsoft/TypeScript/pull/35148https://github.com/microsoft/TypeScript/issues/16577
• コンパイラプラグインhttps://github.com/microsoft/TypeScript/issues/16607https://github.com/microsoft/TypeScript/issues/38736
• ヤーンpnphttps： //github.com/microsoft/TypeScript/issues/28289 https://github.com/microsoft/TypeScript/pull/35206

上記の理由で、不格好でハッキーなソリューションを見るのが一般的です。 ほとんどのreactプロジェクトには、react-hot-loader（コンパイラプラグイン）用のbabelが含まれていますが、一部のCSSシステムでは、コンパイル時の変換にbabelも必要です。 pnp、esm、またはCSSモジュールを使用するには、tscの制限に対してより多くのツールと回避策が必要です。

また、これらの問題のいくつかについて、コミュニティがPRまたは提案の形で具体的な解決策を提供したが、これらは何年にもわたって拒否または停滞したことも苛立たしいことです。 実践者として、より広いエコシステムのコンテキストでTSを使用することはますます難しくなっています。

とにかく私はインターネットからのランダムな人です。

@DanielRosenwasser多分https://github.com/microsoft/TypeScript/pull/29374は4.0に間に合うようにレビューされる可能性がありますか？ this -before- superの人々がよく尋ねるケースの多く（ほとんど？）をカバーしていると思います。

ファイル拡張子を含むファイルパスでESモジュールを参照するためのサポートを含めることを再検討してください。 それは、マルチ環境コードの競争の場を平準化するための大きな後押しを与えるでしょう。

https://github.com/microsoft/TypeScript/issues/16577

typescriptの周りのツールに焦点を当てていただきありがとうございます！ https://github.com/microsoft/tsdocとの緊密な統合を検討していただければ幸いです。 goやrustのような他の多くの現代言語は、箱から出してすぐにドキュメントツールを提供し、開発者に標準のコメントを書くように促しますが、typescriptはこの点で欠けています。

＃31445を手に入れることができれば、それは非常に素晴らしいことです。これは私たちにとって取引のブレーカーであり、多くの人が（その問題の参照数に基づいて）信じています！

https://github.com/microsoft/TypeScript/pull/38967をTypeScript4.0に含めることはできますか、またhttps://github.com/microsoft/TypeScript/pull/35608に含めることもできます。

4.0リリースにすべてを含めるように人々が要求していることがわかりました😆

TSが勢いを失っているように感じますか？ 次の_major_、4.0.0リリースの合体と短絡の割り当てを無効にしますか？ 大きな目標や野心的なアイデアはもうありませんか？

次のメジャーについては、私は期待しています：

• より親切なタイピング
• 依存型？ タイプレベルの関数？ （わかりました、これは5.0.0用にすることができます）
• 記名的型付け
• マクローゼ
• tsconfig.jsonでの変圧器のサポート
• WASMへのコンパイル（一部の言語サブセットの）

@ canonic-epicure同意します。現在、次のバージョンでは3.10のように感じます

TSが勢いを失っているように感じますか？ 次のメジャーな4.0.0リリースの合体と短絡の割り当てを無効にしますか？ 大きな目標や野心的なアイデアはもうありませんか？

TypeScriptはsemverに従いません。 v0.10、v1.10、v2.10、またはv3.10はありません。 したがって、これは実際には通常のマイルストーンです。 4.0でこれほど多くの変更を期待しているのに、3.9またはそれ以前の反復計画では何も言わないのは少し奇妙なことです。 🙈

タイプレベルの関数

type X<T> = Tはあるレベルでそれを行うことができます。 （高階関数はサポートしていません。）

マクローゼ

IMOはTypescriptの目標を満たしていません。

tsconfig.jsonでのトランスフォーマーのサポート

試してみてください： https ：//github.com/cevek/ttypescript

WASMへのコンパイル（一部の言語サブセットの）

https://www.assemblyscript.org/をお探しですか

さて、4.0.0は次のマイナーリリースです。知っておくとよいでしょう。

「マクロスはTSの目標を満たしていない」と「トランスフォーマーにttypescriptを使用する」（ ts-patchの方がうまくいく）-これはジェダイの動きに似ています-「これは必要な機能ではありません」。 いいえ、箱から出してマクロとトランスをお願いします。 それは何年も前に要求されました。

TypeScriptでmarcoも欲しいのですが、これには本当に多くの理由があります。

1. Marcoが異なるJavaScriptコードを生成できる場合、それは新しい非型レベルの構文を作成しているため、ES仕様の拡張です。 enum 、 import x = require(...) 、 moduleはこのルールの例外ですが、これらはTypeScriptの初期のものです。

2. 異なるファイルをクロスして異なるJSファイルを生成するためにMarcoクロスを使用する場合、JavaScriptファイルを取得するためにすべてのタイプの構文をばかげて削除することは不可能です。

3. マルコスは分析とコンパイル時間を増やす可能性があり、悪用される可能性があります。

4. マルコがタイプ情報に基づいて異なるJSファイルを発行できる場合、バベルはこの構文を処理できなくなります。 したがって、この動作はisolatedModulesルールに違反しています（例外： const enumおよびmodule ）

5. マルコが「タイプレベルのマルコ」しか実行できず、Babelによって安全に消去できる場合、それはほとんど役に立たなくなりますが、それでも高階/プログラムタイプには役立ちます。 したがって、それはいかなる目標にも違反していませんが、TypeScriptチームがそのアイデアに興味を持ってくれるかどうかは疑問です。 （https://github.com/Jack-Works/typescript-marco-demo/blob/master/marco-test.tsでデモを作成しました）。

@ Jack-Works私はあなたのポイントを理解していません。 おそらく、マクロがパーサーを拡張し、新しいsynatxを作成することを意味しますか？

私にとって、マクロは単なるAST-> AST関数であり、以前のタイプチェッカーを何らかの形で実行するため、定期的にタイプチェックされる新しいASTノードを作成できます。 ただし、新しい構文は作成されません。入力は通常のASTであり、出力も同様です。 ASTに新しいノードを作成します。

議論はこのスレッドではトピックから外れ、おそらく#compilerチャネルで不和に続けられるのでしょうか？

＃38597をTypeScript 4.0に含めることはできますか？

@DanielRosenwasser

インデックス署名の未定義は興味深い例ですが、現在の仮定の下ですでに動作している人々の90％にとって困難になるような動作を追加したくありません。

それが人々の90％であることをどうやって知っているのか興味がありますか？

@wongjiahau番号は説明のためにさりげなく作成されました。 それがあなたが尋ねている特定のポイントであるかどうかはわかりません。

ヘッドアップの人々と同じように、私たちのチームは6月19日に作業を行わないため、スケジュールを少し延期します。 ベータ版は、6月25日木曜日までに出荷される予定です。

@DanielRosenwasser Typescriptの最初の目的である、エラーになります。

誤解しないでください。コアチームがこのプロジェクトに多大な労力を費やしてくれたことに感謝しますが、代わりにこのプロジェクトの目的に真に一致できれば、もっと良くできたと思います。証明されていない声明がその進歩を妨げることを許すこと。

@wongjiahauミーティングには参加せず、「ダニエルは、その数は90％であり、しきい値の85％を超えていると言ったので、この機能は絶対に実行しないでください」と言いました。 私たちはまだ調査中であり、開発者の需要を十分に認識していますが、この機能が実際にどのように見えるかもテストしており、きれいではないと言えます。

このような私たちからのこのような声明を過度に分析しようとすると、インターネット上で積極的に誤解されるよりもやるべきことがあるので、私たちから得られる声明は少なくなります。

4.0は、「3.9の次のバージョン」ではなく、間違いなくマイルストーンです。

@ typescript-ボット作成リリース-4.0

Heya @DanielRosenwasser 、私はあなたのためにrelease-4.0ブランチを作成し始めました。 これがログでの私の最良の推測へのリンクです。

@Kingwlこれがマイルストーンである場合、それらの大きなものは何ですか、または少なくともヒーロー機能は何ですか？ この号の冒頭にある言語機能リストには、このようなすばらしいものは何もありません。 ほとんどの3.xリリースと比較して異常なことはありません。
もちろん、メジャーバージョンのリリースが必要なのは単なる破壊的な変更であると言うかもしれませんが、それを「マイルストーン」と呼ぶのは難しいです。

@wgebczyk私の意見では、ラベル付きタプル要素を持つ可変個引数タプルがマイルストーンです。

@wgebczyk気にしないでください。 しかし、実際には可変個引数タプルはです。

@xiaoxiangmoe @Kingwlマイルストーン？ インチストーン。

そこにあります： https ：//devblogs.microsoft.com/typescript/announcing-typescript-4-0-beta/#variadic -tuple-types
これはいつ安定バージョンに到達しますか？ VSCodeでのコーディングにこれを毎日適用するのが待ちきれません。

@ mk0yは、8月18日のオープニングメッセージによると。

@wgebczyk私たちのリリースは時間ベースです。 各リリースには、チームの作業の約3か月が含まれています。 私たちのマイルストーンバージョニングポリシー（n = n + 0.1）は、過去20のリリースで一貫しているので、これがいつか人々にとって驚きではなくなることを願っています😅

次のマイナーリリースで、インデックス作成にsymbolタイプを許可することを検討しますか？ プルリクエスト26797を実現してマージできますか？

Heya @DanielRosenwasser 、 release-4.0 4.0.1-rcに更新し始めました。 これがログでの私の最良の推測へのリンクです。

@ typescript-ボット同期リリース-4.0

Heya @DanielRosenwasser 、 release-4.0をマスターと同期し始めました。 これがログでの私の最良の推測へのリンクです。

@ typescript-ボット同期リリース-4.0

Heya @DanielRosenwasser 、 release-4.0をマスターと同期し始めました。 これがログでの私の最良の推測へのリンクです。

@weswigham mmmmmmmmmmmmmmmmmm 、ボットは私を嫌っています）：） ：） ：）：

急ぐことは絶対にありませんが、手動で行い、これを提出しました： https ：//github.com/microsoft/TypeScript/issues/39869

4.0以降のロードマップはどこかにありますか？ 需要がますます高まっているので、＃37582をブーストしたいと思います（＃39965、＃38149、＃27481、＃39965、＃38546）。 それは私には合理的な範囲の問題のように見えます。

更新と同じように、Webサイトの立ち上げや、RCに着陸する必要があると感じたその他の変更のために、RCを2日移動する必要がありました。 これ以上後戻りすることはないと思いますが、安全のために、RCに関するフィードバックを得るためにさらに2日間を費やし、代わりに20日を目指します。

@ typescript-ボットバンプリリース-4.0

Heya @DanielRosenwasser 、 release-4.0 4.0.2に更新し始めました。 これがログでの私の最良の推測へのリンクです。

8月20日です:)

ええ、まだ8月19日です。今から20分後でももう少し待たなければならないと思います。 もう1分もかからない場合は、npmに毎晩リリースがあります。 😄

リリースを待っています。すでにnpmにあります:)

@ typescript-ボットバンプリリース-4.0

Heya @DanielRosenwasser 、 release-4.0 4.0.3に更新し始めました。 これがログでの私の最良の推測へのリンクです。

@ typescript-ボットバンプリリース-4.1

Heya @DanielRosenwasser 、 release-4.1 4.1.1-rcに更新し始めました。 これがログでの私の最良の推測へのリンクです。

大野

@ typescript-ボットバンプリリース-4.0

Heya @DanielRosenwasser 、 release-4.0 4.0.4に更新し始めました。 これがログでの私の最良の推測へのリンクです。

@ typescript-ボットバンプリリース-4.0

Heya @DanielRosenwasser 、 release-4.0 4.0.5に更新し始めました。 これがログでの私の最良の推測へのリンクです。