Typescript: 提案：未定義をインデックス署名に含めるオプション

strictNullChecksを除いて、型システムの動作を変更するフラグはありません。 フラグは通常、エラー報告を有効/無効にします。
| undefinedすべてのインデクサーを定義するライブラリのカスタムバージョンをいつでも使用できます。 期待どおりに動作するはずです。

@mhegazyそれは興味深いアイデアです。 配列/オブジェクトの型シグネチャをオーバーライドする方法に関するガイダンスはありますか？

lib.d.tsはinterface Array<T>があります。 正規表現\[\w+: (string|number)\]で検索して、他のインデックス署名も見つけました。

興味深いので、私はこれを試しました：

{
    // https://github.com/Microsoft/TypeScript/blob/1f92bacdc81e7ae6706ad8776121e1db986a8b27/lib/lib.d.ts#L1300
    declare global {
        interface Array<T> {
            [n: number]: T | undefined;
        }
    }

    const xs = [1,2,3]
    const x = xs[100]
    x // still number :-(
}

何か案は？

lib.d.tsローカルにコピーし、たとえばlib.strict.d.tsとし、インデックスの署名を[n: number]: T | undefined;に変更し、ファイルをコンパイルに含めます。 意図した効果が見られるはずです。

かっこいい、ありがとう。

ここで提案されている修正の問題は、別のlibファイルをフォークして維持する必要があることです。

この機能は、箱から出してすぐに何らかのオプションを保証するのに十分なほど要求されているのだろうか。

ちなみに、ES6コレクションのgetメソッドの型シグネチャ（ Map / Set ）がArrayときにT | undefined返すのは興味深いことです。 Array / Objectインデックス署名はしません。

これは意識的な決定です。 このコードがエラーになるのは非常に面倒です。

var a = [];
for (var i =0; i< a.length; i++) {
    a[i]+=1; // a[i] is possibly undefined
}

そして、すべてのユーザーに!を使用するように依頼するのは不合理です。 または書く

var a = [];
for (var i =0; i< a.length; i++) {
    if (a[i]) {
        a[i]+=1; // a[i] is possibly undefined
    }
}

マップの場合、これは一般的には当てはまりません。

同様に、タイプについては、すべてのインデックス署名に| undefinedを指定でき、期待される動作が得られます。 しかし、 Array場合、それは合理的ではありません。 ライブラリをフォークして、必要な変更を加えることはできますが、現時点では、標準ライブラリの宣言を変更する予定はありません。

宣言の形を変えるためにフラグを追加することは、私たちが行うことではないと思います。

@mhegazyですが、穴のある配列の場合、 a[i]は実際には未定義である可能性があります。

let a: number[] = []
a[0] = 0
a[5] =0
for (let i = 0; i < a.length; i++) {
  console.log(a[i])
}

出力は次のとおりです。

undefined
undefined
undefined
undefined
0

私たちは、誰もが実際にこのフラグから利益を得るだろうということにかなり懐疑的です。 マップやマップのようなものは、定義サイトですでに| undefinedオプトインでき、配列アクセスでEULAのような動作を強制することは成功のようには思えません。 これを口に合うようにするには、CFAとタイプガードを大幅に改善する必要があるでしょう。

誰かがlib.d.tsを変更し、自分のコードのすべてのダウンストリームブレークを修正し、全体的な差分がどのように見えるかを示して、これに何らかの価値提案があることを示したい場合は、そのデータを受け入れます。 あるいは、多くの人がpostfix !もっと使うことに本当に興奮しているが、まだそうする十分な機会がない場合、このフラグはオプションです。

私たちは、誰もが実際にこのフラグから利益を得るだろうということにかなり懐疑的です。 地図や地図のようなものは、定義サイトですでに| undefinedオプトインできます

TypeScriptの目標の1つは、ユーザーが特定のことを覚えている/知っていることに頼るのではなく、「コンパイル」時にエラーをキャッチできるようにすることではありませんか？ これはその目標に反しているようです。 クラッシュを回避するために、ユーザーに何かをするように要求します。 他の多くの機能についても同じことが言えます。 開発者が常にxを実行する場合、これらは必要ありません。 TypeScriptの目標は、（おそらく）作業を簡単にし、これらのことを排除することです。

このバグに遭遇したのstrictNullChecks 、既存のコードで| undefinedで宣言することになっていることを覚えておく（またはさらに悪いことに、知っている）ことに頼ると、TypeScriptは人々が実際に望んでいることを実行できていないように感じます。

私たちは、誰もが実際にこのフラグから利益を得るだろうということにかなり懐疑的です。 地図や地図のようなものはすでにオプトインできます| 定義サイトで未定義
TypeScriptの目標の1つは、ユーザーが特定のことを覚えている/知っていることに頼るのではなく、「コンパイル」時にエラーをキャッチできるようにすることではありませんか？

実際の目標は次のとおりです。

1）エラーである可能性が高い構成を静的に識別します。

ここで議論されていることは、エラーの可能性（TypeScriptチームの意見では低い）と言語の一般的な生産的なユーザビリティです。 CFAへの初期の変更のいくつかは、これらのことをよりインテリジェントに決定するために、警戒心を弱めるか、CFA分析を改善することでした。

TypeScriptチームからの質問は、厳密に正しいことを主張するのではなく、この種の厳密さが一般的な使用法で実際に防御すべきエラーを特定する場所の例を提供することだと思います。

私はこのコメントでもう少し推論に入りましたhttps://github.com/Microsoft/TypeScript/issues/11238#issuecomment-250562397

あなたには、いくつかのオブジェクト（安全な）に対応する性質を持っている知っているもの、あなたには、いくつかのオブジェクト（危険）に対応する性質を持っているか分からないもの：世界で2種類の鍵を考えます。

次のような正しいコードを書くことで、最初の種類のキーである「安全な」キーを取得します。

for (let i = 0; i < arr.length; i++) {
  // arr[i] is T, not T | undefined

また

for (const k of Object.keys(obj)) {
  // obj[k] is T, not T | undefined

2番目の種類は、キーから「危険な」種類、ユーザー入力、ディスクからのランダムなJSONファイル、または存在する可能性があるが存在しない可能性のあるキーのリストなどから取得します。

したがって、危険な種類のキーとそれによるインデックスがある場合は、ここに| undefinedがあると便利です。 しかし、提案は「危険な鍵を危険なものとして扱う」ではなく、「すべての鍵を、安全なものも含めて危険なものとして扱う」というものです。 そして、安全な鍵を危険なものとして扱い始めると、人生は本当にひどいものになります。 あなたは次のようなコードを書きます

for (let i = 0; i < arr.length; i++) {
  console.log(arr[i].name);

TypeScriptは、 arr[i]がundefinedなる可能性があると不平を言っていますが、私は@＃％＃ingでテストしただけです。 今、あなたはこのようなコードを書く習慣を身につけます、そしてそれは愚かだと感じます：

for (let i = 0; i < arr.length; i++) {
  // TypeScript makes me use ! with my arrays, sad.
  console.log(arr[i]!.name);

または多分あなたはこのようなコードを書く：

function doSomething(myObj: T, yourObj: T) {
  for (const k of Object.keys(myObj)) {
    console.log(yourObj[k].name);
  }
}

TypeScriptは「ねえ、そのインデックス式は| undefinedかもしれないので、このエラーをすでに800回見たので、それを忠実に修正します。

function doSomething(myObj: T, yourObj: T) {
  for (const k of Object.keys(myObj)) {
    console.log(yourObj[k]!.name); // Shut up TypeScript I know what I'm doing
  }
}

しかし、あなたはバグを修正しませんでした。 あなたはObject.keys(yourObj) 、または多分myObj[k]を書くつもり

古い「このファイルを削除してもよろしいですか？」と思います。 ダイアログ。 ファイルを削除しようとするたびにそのダイアログが表示された場合、以前はdel押していたときに、 del y押すことをすぐに学び、重要なものを削除しない可能性が前にリセットされます-ダイアログベースライン。 代わりに、ファイルがごみ箱に移動していないときにファイルを削除しているときにのみダイアログが表示された場合は、意味のある安全性が得られます。 ただし、オブジェクトキーが安全かどうかはわかりません（また、安全かどうかもわかりません）。そのため、「そのオブジェクトにインデックスを付けてもよろしいですか？」と表示します。 ダイアログを実行するたびに、すべてを表示しないよりも良いレートでバグを見つけることはできません。

エラーの可能性が高い構成を静的に識別します。

おそらく、これを修正して、「他の構成よりもエラーであるウィンク：。 基本的に「 /を使用するつもりだったときにます。

私は理解していますが、範囲外のインデックスは現実的で一般的な問題です。 これができない方法で配列を列挙するように人々に強制することは悪いことではありません。

!の修正私も実際には嫌いです-誰かがやって来て、仮定が無効になるように変更した場合はどうなりますか？ スクエア1に戻ります（コンパイラーがキャッチする必要がある何かの潜在的なランタイム障害）。 型について嘘をついたり、 !を使用したりすることに依存しない配列を列挙する安全な方法があるはずです（たとえば、 array.forEach(i => console.log(i.name)ようなことはできませんか？）。

あなたはすでにコードに基づいて型を絞り込んでいるので、理論的には安全なパターンを見つけて型を絞り込み、そのような場合に| undefinedを削除して、両方の長所を生かすことができませんでしたか？ 有効な要素にアクセスしていないことをコンパイラに簡単に伝えることができない場合は、保証が無効であるか、将来誤って簡単に破られる可能性があると私は主張します。

とは言うものの、私は1つのプロジェクトでTSを使用するだけであり、それは最終的にDartに移行されるため、私に実際の違いをもたらす可能性はほとんどありません。 ソフトウェアの一般的な品質が悪く、便宜上無視されているように見えるエラーをここで排除するのに役立つ機会があるのは悲しいことです。 型システムをしっかりと作り、これらの穴を導入しない方法で一般的な煩わしさを解決できると確信しています。

とにかく、それは私の2セントです..これを引きずり出したくない-私たちがどこから来ているのかを理解していると確信しており、私よりもこれについて決定を下すのにはるかに適しています:-)

考慮すべきことがいくつかあると思います。 要素の数を説明する、一般的に使用されている配列を反復処理するためのパターンはたくさんあります。 配列のインデックスにランダムにアクセスすることは可能なパターンですが、実際には非常にまれなパターンであり、静的エラーになる可能性はほとんどありません。 反復する最新の方法がありますが、最も一般的な方法は次のようなものです。

for (let i = 0; i < a.length; i++) {
  const value = a[i];
}

予備の配列が一般的ではないと仮定した場合（そうです）、 valueを| undefinedことはほとんど役に立ちません。 これが危険である（そしておそらくエラーである）一般的なパターンが実際にある場合、TypeScriptはこれを考慮するように耳を傾けると思いますが、一般的に使用されているパターンは、インデックスアクセスが未定義であることは明らかに生産性に影響を与えるものであり、指摘されているように、それが潜在的に有用である状況にある場合はオプトインできます。

値の相互依存性を表現する方法（たとえば、Array.prototype.lengthはインデックス値に関連する）を使用して、範囲外のインデックスなどを静的に分析できるようにするために、CFAを改善することについて以前に話し合ったことがあると思います。 明らかに、それは重要な作業であり、私が理解したくないあらゆる種類のエッジケースと考慮事項を考慮して作成されています（ただし、アンダースはこのようないくつかのことで冷たい汗で目を覚ます可能性があります）。

したがって、トレードオフになります... CFAの改善がなければ、コードの90％を赤いニシンで複雑にして、潜在的に10％の不良コードをキャッチし

TypeScriptが私たちを自分たちから救うためにできることはたくさんあります。

このすべての焦点は配列にあり、そこで問題になる可能性は低いと私は同意しますが、（私のように）提起された元の問題のほとんどは、一般的なケースが常に存在するとは思わないマップに関するものでしたか？

このすべての焦点は配列にあり、そこで問題になる可能性は低いと私は同意しますが、（私のように）提起された元の問題のほとんどは、一般的なケースが常に存在するとは思わないマップに関するものでしたか？

これがあなたのタイプである場合は、インデックス署名に| undefinedを追加してください。 --noImplicitAny下にインデックス署名のないタイプにインデックスを付けることはすでにエラーです。
ES6 Mapは、getをget(key: K): V | undefined;としてすでに定義されています。

配列とマップのすべての定義を書き直して、インデックス署名が| undefined返すようにしましたが、それ以来後悔することはありませんでした。いくつかのバグが見つかりました。チェックを維持する手作りのライブラリを介して間接的に配列を操作するため、不快感はありません。未定義またはその中の!の場合

TypeScriptがC＃のようにチェックのフローを制御できれば（プロセッサ時間を節約するためにインデックス範囲チェックを排除するため）、次のようになります。

declare var values: number[];
for (let index = 0, length = values.length; index< length; index ++) {
   const value = value[index]; // always defined, because index is within array range and only controlled by it
}

（まばらな配列を使用する人へ-熱く燃える火で自殺してください）

Object.keysに関しては、制御フロー分析に安全なナローイングを実行させるには、 allkeysof T特別なタイプが必要です。

今は基本的にインデックス操作のタイプについて嘘をついていて、オブジェクトタイプに| undefinedを追加するのを忘れがちなので、これは良いオプションだと思います。 undefinedを無視したい場合に、 !を追加することは、このオプションが有効になっている場合のインデックス作成操作を処理するための優れた方法だと思います。

オブジェクトタイプ定義に|undefinedを入れることには、（少なくとも）他に2つの問題があります。

• これは、これらのオブジェクトに未定義を
• Object.values （または_.values ）などの他の操作では、結果でundefinedを処理する必要があります

typescriptが間違った型情報を返すため（= | undefined ）、tslintは一定の状態の誤検知警告を報告します。
https://github.com/palantir/tslint/issues/2944

配列のインデックスに| undefinedがないために定期的にスキップされるエラーの1つは、 find代わりに使用した場合のこのパターンです。

const array = [ 1, 2, 3 ];
const firstFour = array.filter((x) => (x === 4))[0];
// if there is no `4` in the `array`,
// `firstFour` will be `undefined`, but TypeScript thinks `number` because of the indexer signature.

const array = [ 1, 2, 3 ];
const firstFour = array.find((x) => (x === 4));
// `firstFour` will be correctly typed as `number | undefined` because of the `find` signature.

私は間違いなくこのフラグを使用します。 はい、古いforループは扱いにくいものですが、定義されていることがわかったときにコンパイラーに通知する!演算子があります。

for (let i = 0; i < arr.length; i++) {
  foo(arr[i]!)
}

また、この問題は新しい、はるかに優れたfor ofループの問題ではなく、古いスタイルのforループを使用しないように指示するTSLintルールprefer-for-ofもあります。もう。

現在、型システムは開発者にとって一貫性がないように感じます。 array.pop()はifチェックまたは!アサーションが必要ですが、 [array.length - 1]経由でアクセスする必要はありません。 ES6 map.get()はifチェックまたは!アサーションが必要ですが、オブジェクトハッシュには必要ありません。 @sompylasarの例も良いです。

別の例は破壊です：

const specifier = 'Microsoft/TypeScript'
const [repo, revision] = specifier.split('@') // types of repo and revision are string
console.log('Repo: ' + repo)
console.log('Short rev: ' + revision.slice(0, 7)) // Error: Cannot call function 'slice' on undefined

コンパイラが私にこれを強制した場合、私は好んだでしょう：

const specifier = 'Microsoft/TypeScript'
const [repo, revision] = specifier.split('@') // types of repo and revision are string | undefined
console.log('Repo: ', repo || 'no repo')
console.log('Short rev:', revision ? revision.slice(0, 7) : 'no revision')

これらは私が見た実際のバグであり、コンパイラーによって防止できた可能性があります。

Imoこれは型ファイルに属するべきではなく、型システムの仕組みである必要があります-インデックス署名のあるものにアクセスするときは、 undefinedなる可能性があります。 ロジックで正しくないことが確認された場合は、 ! 。 それ以外の場合はifを追加すれば、問題ありません。

多くの人は、キャッチされていないバグで緩むよりも、必要なアサーションでコンパイラを厳密にすることを好むと思います。

このフラグを追加してほしいです。 私の会社のコードベースでは、配列のランダムアクセスはまれな例外であり、 forループは、通常、高階関数で書き直したいコードの臭いです。

@pelotomでは、あなたの懸念は何

@ aleksey-bykovは主にオブジェクトインデックス署名であり、サードパーティライブラリで広く発生します。 { [k: string]: A }プロパティにアクセスして、結果が未定義である可能性があることを警告したいと思います。 配列のインデックス付けについては、フラグが煩わしくて操作できない理由として取り上げられたため、ここでのみ説明しました。

あなたはあなたがあなたが望むようにそれらを正確に書き直すことができることを知っていますか？ （少し余分な作業があります）

はい、全員の入力を書き直すことも、コンパイラフラグをオンにすることもできます😜

キャプテンOをプレイし続けてください...：今日lib.d.tsを書き直して、より多くのサウンドコードベースの幸せな所有者になるか、次のN年間旗を待つことができます

@ aleksey-bykov lib.d.ts書き換えることでどのようにそれを行うことができますか？

declare type Keyed<T> = { [key: string]: T | undefined; }

その後にArrayでdefintion lib.es2015.core.d.ts 、交換してください

[n: number]: T;

と

[n: number]: T | undefined;

@ aleksey-bykov多分あなたは私が配列を気にしないと言った部分を見逃したでしょう。 サードパーティのライブラリが{ [k: string]: T }型の何かを宣言している場所が気になり、そのようなオブジェクトにアクセスして、おそらく未定義のものを返すようにします。 lib.d.ts編集するだけでそれを達成する方法はありません。 問題のライブラリの署名を変更する必要があります。

サードパーティの定義ファイルを管理できますか？ もしそうなら、あなたはそれらを修正することができます

そして今、私たちは戻ってきました

はい、全員の入力を書き直すことも、コンパイラフラグをオンにすることもできます😜

時間は平らな円です。

ばかげてはいけません、あなたは「みんなのタイピング」を使わないのですか？ それは文字通り、典型的なプロジェクトの最大作業日です。

はい、私は常に他の人のタイピングを編集する必要があり、それを減らしたいと思っています。

そして、あなたはN年以内に、多分、今のところあなたは苦しむか、または人を増やすことができます

信じられないほど建設的な入力をありがとう👍

これに対する建設的な入力は次のとおりです。次の理由により、この問題を解決する必要があります。
NS。 [x]をundefinedすることができるかどうかの決定は、開発者に任されています。

• 以前と同じように、すべてを頭の中に入れておく
• または提案されたようにlib.d.tsと3rd-party.d.tsを変更することによって

NS。 または、＃aで手作業で簡単に実行できることを軽減するには、特別な構文/タイプ/フロー分析/ N年かかります。

問題は（b）の提案ですが、新しい構文は提案されておらず、コンパイラフラグにすぎません。

結局のところ、タイプ{ [x: string]: {} }はほとんどの場合嘘です。 Proxyの使用を除けば、無限の数のプロパティを持つことができるオブジェクトはありません。可能なすべての文字列ははるかに少ないです。 提案は、これを認識するコンパイラフラグを持つことです。 得られたものに対してこれを実装するのは難しすぎるかもしれません。 その呼び出しは実装者に任せます。

重要なのはどちらも

• T | undefined
• T

一般的なケースに適しています

一般的なケースに正しくするために依存型システムを必要とするコンテナーの型にエンコードする必要があります...それ自体は悪いことではありません:)しかし、編集を節約するために、現在までに行われているすべてのtypescript型システムと同じくらい複雑かもしれません。

T | undefinedは、先ほど説明した理由により、一般的なケースでは正しいです。 依存型についての無意味なとりとめのない話を無視して、良い一日を過ごしましょう。

あなたは私を好きなだけ無視することができますが、 T | undefinedは

declare var items: number[];
for (var index = 0; index < items.length; index ++) {
   void items[index];
}

私はむしろ持っていると思いますT | undefined 、デフォルトでそこをしていることをコンパイラに伝えるindexの数値インデックスの範囲であるitems境界た場合に適用されたときに出ていないので、 items ; 頻繁に使用される一連のfor / whileループ形状などの単純なケースでは、コンパイラーはそれを自動的に推測できます。 複雑なケースでは、申し訳ありませんが、 undefinedが存在する可能性があります。 はい、ここでは値ベースのタイプが適しています。 リテラル文字列型は非常に便利ですが、リテラルブール型と数値型および範囲/範囲のセット型を使用してみませんか？ TypeScriptに関する限り、JavaScriptで表現できるすべてのものをカバーしようとします（たとえば、それを制限するElmとは対照的です）。

それは文字通り、典型的なプロジェクトの最大作業日です。

@ aleksey-bykov、その変更後のあなたの経験はどうでしたか？ !どのくらいの頻度で使用する必要がありますか？ コンパイラが実際のバグにフラグを立てているのをどのくらいの頻度で見つけますか？

@mhegazy正直なところ、 TからT | undefinedに移動しても大きな違いは見られませんでした。バグも見つかりませんT私の問題は、 !を保持するユーティリティ関数を介して配列を操作することだと思います。それらには

https://github.com/aleksey-bykov/basic/blob/master/array.ts

オブジェクトのインデックスタイプ定義は、どのlibファイルで見つけることができますか？ Arrayを[n: number]: Tから[n: number]: T | undefined更新しました。 オブジェクトに対しても同じことをしたいと思います。

インデックスシグネチャを持つオブジェクトの標準インターフェイス（配列のArrayなど）はありません。コード内のケースごとに正確な定義を探して修正する必要があります。

コード内のケースごとに正確な定義を探して修正する必要があります

直接キールックアップはどうですか？ 例えば

const xs = { foo: 'bar' }
xs['foo']

ここでT代わりにT | undefinedを強制する方法はありますか？ 現在、配列とオブジェクトのインデックスルックアップのタイプセーフな代替手段として、コードベースのあらゆる場所でこれらのヘルパーを使用しています。

// TS doesn't return the correct type for array and object index signatures. It returns `T` instead
// of `T | undefined`. These helpers give us the correct type.
// https://github.com/Microsoft/TypeScript/issues/13778
export const getIndex = function<X> (index: number, xs: X[]): X | undefined {
  return xs[index];
};
export const getKeyInMap = function<X> (key: string, xs: { [key: string]: X }): X | undefined {
  return xs[key];
};

@mhegazyこれを書いているときに、 https： //unsplash.comでの本番環境のバグを修正しています。このバグは、より厳密なインデックス署名タイプで検出された可能性があります。

なるほど、マップされた型演算子を検討してください。

const xs = { foo: 'bar' };
type EachUndefined<T> = { [P in keyof T]: T[P] | undefined; }
const xu : EachUndefined<typeof xs> = xs;
xu.foo; // <-- string | undefined

フラグはlib.d.tsファイルを変更するように設計されていないため、 --strictArrayIndexようなフラグがオプションではない場合。 たぶんあなたたちは「 lib": ['strict-es6'] ？」のようなlib.d.tsファイルの厳密なバージョンをリリースすることができますか？

厳密な配列インデックスだけでなく、複数の改善が含まれる可能性があります。 たとえば、 Object.keys ：

interface ObjectConstructor {
    // ...
    keys(o: {}): string[];
}

になり得る：

interface ObjectConstructor {
    // ...
    keys<T>(o: T): (keyof T)[];
}

今日のSBSからの更新：私たちは30分間お互いに怒鳴りましたが、何も起こりませんでした。 🤷‍♂️

@RyanCavanaugh好奇心から、SBSとは何ですか？

@radix 「提案バック

解決策が明らかであるため、それは興味深いものです。
TとT | undefined両方が間違っています。唯一の正しい方法は、セットから選択するか、既知の数値範囲で囲むことにより、インデックス変数にコンテナの容量を認識させることです。

@RyanCavanaugh私はこれについて考えていましたが、次のトリックがすべてのケースの87％をカバーするようです：

• values[index]与えTインデックスがで宣言された場合はfor (HERE; ...)
• values[somethingElse]は、 for外部で宣言されたすべての変数にT | undefinedを与えます

@ aleksey-bykovさらに賢いことについて話し合いました。「 arr[index]はindex < arr.lengthによってテストされました。しかし、それはpop場合には役に立ちません。ループの途中で

_{Alekseyがアレイを変更することを意味するものではありません}

最近、アプリをElmからTypescriptに移植しましたが、インデックス作成操作が正しく入力されていないことが、TSの最も厳しい設定がすべて有効になっている（ thisもバインドされていない）問題の最大の原因の1つである可能性があります。 ）。

• コンテナへの変異を追跡することはできません
• インデックス操作を追跡することはできません

これではほとんど保証できませんが、もしそうなら、典型的なユースケースが< array.length内のすべての要素を介したばかげた反復である場合でも、なぜ試してみるのでしょうか。

私がいつも言ったように

• エラーがある場合は、 forステートメントの句のどこかで発生している可能性があります。初期化、増分、停止条件であり、完全な型チェックを行う必要があるため、確認できません。
• for句の外では、通常、エラーの場所

インデックスが何らかの形で宣言されている限り（自信を持ってそれについて言うことはできません）、ループ本体でインデックスが正しいと信じることは合理的に公正です

しかし、ループの途中でポップしたり、配列から要素を削除する関数に配列を渡したりした場合は役に立ちません。

これはこれに対して本当に弱い議論のようです。 それらのケースはすでに壊れています-他のケースを修正しない言い訳としてそれらを使用することは意味がありません。 ここでは、これらのケースのいずれかが正しく処理されること、または100％正しいことを求めている人は誰もいません。 本当に一般的なケースでは、正確な型が必要です。 TypeScriptには、完全に処理されないケースがたくさんあります。 何か変なことをしている場合は、タイプが間違っている可能性があります。 この場合、私たちは奇妙なことを何もしておらず、タイプが間違っています。

コードを修正するための式典の追加

これが「コードを修正するための式典の追加」であるコード例を見てみたいと思います。 私が理解しているように、配列上の基本的なforループは、簡単に検出/絞り込むことができます。 これが不便になり、潜在的にバグではない単純なforループでは何ですか？ （現在、または将来の些細な変更による可能性があります）。 何もないと言っているのではありません。 私はそれを想像することができず、例も見ていません（forループを使用した例をたくさん見ましたが、これらを絞り込むことができないと言わない限り、それらは無関係のようです）。

虫を捕まえずに

このためにコンパイルに失敗する動作中のコードと、型が開発者を誤解させるために実行時にスローされるコードの両方の例があります。 これをサポートすることに価値がないと言うのはナンセンスです。

単純に保つことができず、古いスタイルのforループの周りに魔法の振る舞いをまったく追加しないのはなぜですか。 いつでも!を使用して機能させることができます。 コードベースが古いスタイルのforループでいっぱいの場合は、フラグを使用しないでください。 私が使用したすべての最新のコードベースは、 forEachまたはfor ofいずれかを使用して配列を反復し、これらのコードベースは追加の型安全性の恩恵を受けます。

変なことは何もしておらず、タイプが間違っています。

この段落は、私には、この機能を持たない正当な理由のように読めます。 範囲外の配列にアクセスするのは奇妙なことです。 珍しいこと（OOBing）をしている場合にのみ、タイプは「間違っている」。 配列から読み取るコードの大部分は、インバウンドで行います。 このような場合、この引数でundefinedを含めるのは「間違っている」でしょう。

...コンパイルに失敗する作業コード

私は何も知りません-具体的にそれらを指摘できますか？

なぜそれを単純に保ち、古いスタイルのforループの周りに魔法の振る舞いをまったく追加しないことができないのですか？ いつでも使えます！ 物事を機能させるために。

これと、「すべての配列アクセス式には末尾に!必要」というTSLintルールとの便利な違いは何ですか？

@RyanCavanaugh私の仮定では、TSLintルールは型を絞り込んだり、制御フロー型分析を使用したりすることはできません（たとえば、アクセスをifでラップする、例外をスローする、 return ingまたはcontinue設定されていない場合はhttps://github.com/Microsoft/TypeScript/issues/13778#issuecomment -336265143の例の実装はどのようになり!を適用するには、基本的に、これらの変数のタイプをおそらくundefinedとして追跡するためのテーブルを作成する必要があります。 私には、リンターではなく、タイプチェッカーが行うべきことのように聞こえます。

@RyanCavanaugh

この段落は、私には、この機能を持たない正当な理由のように読めます。 範囲外の配列にアクセスするのは奇妙なことです。 珍しいこと（OOBing）をしている場合にのみ、タイプは「間違っている」。

...コンパイルに失敗する作業コード

私は何も知りません-具体的にそれらを指摘できますか？

私の場合、それは配列ではありませんでしたが、重複として閉じられていたので、この問題はこれらもカバーしていると思われます。 私の元の問題については＃11186を参照してください。 ファイルをマップに解析してから、 undefinedと照合していました。 IIRC比較の結果、定義できなかったとしても、定義できなかったというエラーが発生しました。

何かをundefinedと比較することは常に許可されています

残念です

const canWeDoIt = null === undefined; // yes we can!

何かをundefinedと比較することは常に許可されています

とても長い間、エラーが何であったかを正確に覚えていないのではないかと思います。 （ strictNullChecks ）正常に機能しているコードで間違いなくエラーが発生し、上記のケースの結果となったテストにつながりました。

時間があれば、また何だったのか正確に理解できるかどうかを確認します。 それは間違いなくこのタイピングに関連していた。

この議論のほとんどは配列に焦点を当てていますが、私の経験では、オブジェクトアクセスがこの機能が最も役立つ場所です。 たとえば、私のコードベースからのこの（簡略化された）例は、合理的に見え、正常にコンパイルされますが、間違いなくバグです：

export type Chooser = (context?: Context) => number | string;
export interface Choices {
    [choice: number]: Struct;
    [choice: string]: Struct;
}

export const Branch = (chooser: Chooser, choices: Choices, context?: Context): Struct => {
    return choices[chooser(context)];  // Could be undefined
}

オブジェクトに関して、 | undefinedを含むように署名を変更するだけで、 @types/nodeはprocess.envます。

    export interface ProcessEnv {
        [key: string]: string | undefined;
    }

ただし、タイプを絞り込むことはできません。

process.env.SOME_CONFIG && JSON.parse(process.env.SOME_CONFIG)

与える

[ts]
Argument of type 'string | undefined' is not assignable to parameter of type 'string'.
  Type 'undefined' is not assignable to type 'string'.

@felixfbecker

私はそれがこのバグに関連していると信じています： //github.com/Microsoft/TypeScript/issues/17960

env varを変数に割り当て、それを保護することで回避できます。

const foo = process.env.SOME_CONFIG
foo && JSON.parse(foo);

一部のノード型に| undefinedを追加することは、コード補完を取得するために頻繁に使用されるプロパティを使用して、これらのインターフェイスを便利に拡張できるようにするために行われました。 ea

interface ProcessEnv {
  foo?: string;
  bar?: string;
}

インデックス署名に| undefinedがないと、TSCはProperty 'foo' of type 'string | undefined' is not assignable to string index type 'string'.文句を言います。

余分な| undefinedがあるタイプとないタイプで作業する必要がある場合、これにはコストがかかることを私は知っています。

これを取り除くことができれば本当にいいでしょう。

私はこの問題についての私の考えを集めようとしています。

オブジェクトはJavaScriptの混合バッグです。 それらは2つの目的に使用でき

• キーが不明な辞書、別名マップ
• キーがわかっているレコード

レコードとして使用されるオブジェクトの場合、インデックス署名を使用する必要はありません。 代わりに、既知のキーがインターフェイスタイプで定義されます。 有効なキールックアップは対応するタイプを返し、無効なキールックアップはインデックスシグネチャにフォールバックします。 インデックス署名が定義されておらず（レコードとして使用されるオブジェクトには存在しないはずです）、 noImplicitAnyが有効になっている場合、これは必要に応じてエラーになります。

ディクショナリ（別名マップ）および配列として使用されるオブジェクトの場合、インデックスシグネチャが使用され、値の型に| undefinedを含めることを選択できます。 たとえば、 { [key: index]: string | undefined }です。 すべてのキールックアップは有効であり（コンパイル時にキーが不明であるため）、すべてのキーが同じタイプを返します（この例ではT | undefined ）。

インデックス署名はディクショナリオブジェクトのパターンと配列にのみ使用する必要があるため、TypeScriptはインデックス署名値タイプに| undefinedを適用する必要があります。キーが不明で、キールックアップがundefined返す可能性がある場合

Array.prototype.find undefined返す、またはarray[0] undefined返すなど、これがないと見えないバグの良い例があります。 （デストラクチャリングは、キールックアップの単なる糖構文です。） getKeyような関数を記述して戻り型を修正することは可能ですが、コードベース全体でこれらの関数の使用を強制するには、規律に依存する必要があります。

私が正しく理解していれば、問題は辞書オブジェクトと配列の反映に関するものになり、辞書オブジェクトまたは配列のキーをマッピングするときに、キールックアップが有効であることがわかっている、つまりundefined返されません。 この場合、値型にundefinedを含めることは望ましくありません。 これを修正するために制御フロー分析を使用できる場合があります。

これは未解決の問題ですか、それとも私は誤解していますか？

私が言及していないユースケースと問題はどれですか？

オブジェクト型定義に| undefinedを入れることには、（少なくとも）他に2つの問題があります。

• これは、これらのオブジェクトに未定義を割り当てることができることを意味しますが、これは絶対に意図されたものではありません
• Object.values（または_.values）などの他の操作では、結果で未定義を処理する必要があります

これは非常に重要なポイントだと思います。

現在、私は次のアプローチを試しています。

const safelyAccessProperty = <T, K extends keyof T>(object: T, key: K): T[K] | undefined => object[key];定義する

次に、 myObject[myKey]ではなく、 safelyAccessProperty(myObject, myKey)などのプロパティにアクセスします。

@plulグッドキャッチ。 現在、議論は読み取り操作に焦点を合わせていますが、インデクサー型の定義は実際には2つあり、 | undefinedを追加すると、 undefined値を書き込むことができます。

実験しているsafelyAccessProperty関数（@OliverJAshによってgetKeyとして前述）には、すべての配列とオブジェクトでのインデックス作成操作を禁止するための規律やリンタールールが必要です。

C ++のように、すべての配列インスタンスとオブジェクトインスタンス（インデクサー操作を提供するすべてのタイプ）で関数が提供されている場合、これをスケーラブルにすることができます。 std::vectorは.at()あり、OOBアクセスの実行時に例外をスローします。 、およびチェックされていない[]演算子は、最良の場合はOOBアクセスでSEGFAULTでクラッシュし、最悪の場合はメモリを破壊します。

OOBアクセスの問題は、TypeScript / JavaScriptでは型定義レベルだけでは解決できないと思います。この厳密性機能が有効になっている場合、潜在的に危険なインデクサー操作を制限するための言語サポートが必要です。

インデクサーの2つの性質は、 getおよびset操作を関数として持つプロパティとしてモデル化できますが、これは既存のすべてのインデクサータイプ定義にとって重大な変更になります。

有望と思われるアイデアの1つは、インデックス署名を定義するときに?:使用して、通常の使用では値が欠落することがあることを示すことができるとしたらどうでしょうか。 上記の| undefinedように動作しますが、厄介な欠点はありません。 明示的なundefined値を禁止する必要があります。これは、通常の?:との違いだと思います。

次のようになります。

type NewWay = {[key: string]?: string};
const n: NewWay = {};

// Has type string | undefined
n['foo']

// Has type Array<string>
Object.values(n)

// Doesn't work
n['foo'] = undefined;

// Works
delete n['foo'];

| undefinedの以前のアプローチと比較して：

type OldWay = {[key: string]: string | undefined};
const o: OldWay = {};

// Has type string | undefined
o['foo']

// Has type Array<string | undefined>
Object.values(o)

// Works
o['foo'] = undefined;

// Works
delete o['foo'];

上記のDTPRに| undefinedを追加することを拒否することからここに来ました。これは、そのAPIの既存のすべてのユーザーを壊してしまうためです。図書館より？

オプションのプロパティによって| undefinedも追加されることに注意してください。これは、私を何度か噛みました。基本的に、TSは、欠落しているプロパティと未定義に設定されているプロパティを区別しません。 { foo?: T, bar?: T }を{ [name: 'foo' | 'bar']: T }と同じように扱いたいのですが、どちらの方法でもかまいません（上記のprocess.envコメントも参照してください）。

TSは、ここで数値と文字列のインデクサの対称性を破ることに反対していますか？

foo[bar] && foo[bar].baz()は非常に一般的なJSパターンであり、TSでサポートされていない場合は不器用に感じます（ | undefined追加しない場合は追加する必要があることを思い出させ、追加された場合は警告するという意味で）明らかに必要ありません）。

ガード式の保証を破る反復中に配列を変更することに関しては、他のガードでも可能です。

class Foo {
    foo: string | number = 123

    bar() {
        this.foo = 'bar'
    }

    broken() {
        if (typeof this.foo === 'number') {
            this.bar();
            this.foo.toLowerCase(); // right, but type error
            this.foo.toExponential(); // wrong, but typechecks
        }
    }
}

しかし、実際のコードでは、古いループがiterateeを変更する可能性ははるかに低いと思います。

この機能に対する需要があることは明らかです。 TSチームが解決策を見つけてくれることを本当に望んでいます。 インデクサーには独自の問題があるため（すでに説明） | undefinedを追加するだけでなく、より「賢い」方法で（読み取りはT|undefined返し、書き込みにはTが必要です。優れたコンパイラー） forループなどをチェックします。良い提案もすでに言及されています。）

配列を変更して操作するときは、実行時エラーで問題ありません。コンパイラーの方法で検証するのは困難です。 ほとんどの場合、エラーチェックが必要であり、 !を使用しても問題ありません。

そうは言っても、このより厳密な配列の処理を実装すると、＃24897を使用して、定数で配列の長さをチェックするときに、適切な型の絞り込みを実装できるようになります。 配列をREST要素でタプルに狭めることができます。

let arr!: string[];
if (arr.length == 3) {
  //arr is of type [string, string, string]
}

if (arr.length > 3) {
  //arr is of type [string, string, string, string, ...string[]]
}

if (arr.length) {
  //arr is of type [string, ...string[]]
}

if (arr.length < 3) {
  //arr is of type [string?, string?, string?]
  if (arr.length > 0) {
    //arr is of type [string, string?, string?]
  }
}

定数でインデックスを作成したり、配列を分解したりする場合に便利です。

let someNumber = 55;
if (arr.length) {
  let el1 = arr[0]; //string
  let el2 = arr[1]; //string | undefined
  let el3 = arr[someNumber]; //string | undefined
}

if(arr.length >= 3){
    let [el1, el2, el3, el4] = arr;
    //el1, el2, el3 are string
    // el4 is string | undefined    
}

if (arr.length == 2){
    let [el1, el2, el3] = arr; //compiler error: "Tuple type '[string, string]' with length '2' cannot be assigned to tuple with length '3'.",
}

他の質問は、次のような大きな数で何をするかです。

if(arr.length >= 99999){
    // arr is [string, string, ... , string, ...string[]]
}

この巨大なタプルのタイプをIDEまたはコンパイラメッセージに表示することはできません。

「すべてのアイテムで同じタイプの特定の長さのタプル」を表す構文があると思います。 したがって、たとえば、1000文字列のタプルはstring[10000]あり、上記の例のナロー配列のタイプは[...string[99999], ...string[]]ます。

もう1つの懸念は、コンパイラインフラストラクチャがこのような大きなタプルをサポートできるかどうか、そうでない場合はそれを行うのがどれほど難しいかということです。

オブジェクト

私は常に[key: string (or number, symbol)]: V | undefinedインデックスタイプが必要ですが、 undefined場合を忘れることがあります。 開発者がコンパイラに「私を信じてください、これは本当の意味でのタイプです」と明示的に伝えなければならないときはいつでも、あなたはそれが安全でないことを知っています。
Map.get正しく（厳密に）入力することはほとんど意味がありませんが、どういうわけかプレーンオブジェクトはフリーパスを取得します。
それでも、これはユーザーランドで簡単に修正できるので、それほど悪くはありません。 とにかく、私には解決策がありません。

配列

何かが足りないかもしれませんが、「安全でない方法で配列にアクセスすることはほとんどない」という議論は、特に新しいコンパイラフラグを使用すると、双方向に進む可能性があります。

私はますます多くの人々がこれらの2つのベストプラクティスに従うと思う傾向があります。

• 関数型のネイティブメソッドまたはライブラリを使用して、配列を反復または変換します。 ここにはブラケットアクセスはありません。
• アレイを所定の位置で変更しないでください

これを念頭に置いて、低レベルのブラケットアクセスロジックが必要な唯一の残りのまれなケースは、型安全性から本当に恩恵を受けるでしょう。

これは簡単なことのように思えます。lib.d.ts全体をローカルにコピーして貼り付けることは、許容できる回避策ではないと思います。

配列/オブジェクトに明示的にインデックスを付ける場合、たとえば配列の最初の項目（ array[0] ）を取得する場合、結果にundefinedを含める必要があります。

これは、インデックス署名にundefinedを追加することで可能になります。

ただし、正しく理解していれば、インデックス署名にundefinedを含める場合の問題は、配列またはオブジェクトにマッピングするときに、値にundefinedが含まれることです。 undefined （そうでない場合、それらをマッピングしません）。

インデックスタイプ/シグネチャは、インデックスルックアップ（例： array[0] ）とマッピング（例： forループとArray.prototype.map ）の両方に使用されますが、これらのケースごとに異なるタイプが必要です。

Map.getは関数であるため、これはMap問題ではありません。したがって、関数ではない配列/オブジェクトへのインデックス付けとは異なり、その戻り型は内部値型から分離できます。したがって、インデックス署名を直接使用します。

したがって、問題は次のようになります。両方のケースをどのように満たすことができるでしょうか。

// Manually adding `undefined` to the index signature
declare const array: (number | undefined)[];

const first = array[0]; // number | undefined, as desired :-)
type IndexValue = typeof array[0]; // number | undefined, as desired! :-)

array.map(x => {
  x // number | undefined, not desired! :-(
})

提案

インデックス値タイプにundefinedを含めることにより、 Set.getおよびMap.get入力方法と同様に、インデックスルックアップ（ array[0] ）を処理するコンパイラオプションインデックス署名自体）。 実際のインデックス署名自体にはundefinedが含まれないため、マッピング機能は影響を受けません。

例：

declare const array: number[];

// The compiler option would include `undefined` in the index value type
const first = array[0]; // number | undefined, as desired :-)
type IndexValue = typeof array[0]; // number | undefined, as desired :-)

array.map(x => {
  x // number, as desired :-)
})

ただし、この手法ではインデックスルックアップを使用するため、 forループを使用して配列/オブジェクトをループする場合は解決されません。

for (let i = 0; i < array.length; i++) {
  const x = array[i];
  x; // number | undefined, not desired! :-(
}

私と他の多くの人にとっては、 forループが使用されておらず、代わりにArray.prototype.map機能的なスタイルを使用することを好むため、これは許容できます。 それらを使用する必要がある場合は、ここで提案されているコンパイラオプションをnull以外のアサーション演算子と一緒に使用できれば幸いです。

for (let i = 0; i < array.length; i++) {
  const x = array[i]!;
  x; // number, as desired :-)
}

また、オプトインまたはオプトアウトする方法を提供することもできます。たとえば、インデックス署名を装飾するための構文を使用します（例として思いついたあいまいな構文はご容赦ください）。 この構文は、インデックスルックアップに必要な動作を通知する方法にすぎません。

オプトアウト（コンパイラオプションはデフォルトで有効になり、必要に応じてオプトアウトします）：

declare const array: { [index: number]!!: string };

declare const dictionary: { [index: string]!!: string }

オプトイン（コンパイラオプションなし、必要に応じてオプトインするだけ）：

declare const array: { [index: string]!!: string };

declare const dictionary: { [index: string]??: string }

この問題や長所と短所、さまざまな提案などについては読んでいません（配列/オブジェクトへのアクセスが厳密なヌルチェックで一貫して処理されないことに繰り返し驚いた後、Googleで見つけました）が、私は持っています関連する提案：特にオーバーライドされない限り、配列型の推論を可能な限り厳密にするオプション。

例えば：

const balls = [1, 2 ,3];

デフォルトでは、 ballsは[number, number, number]として扱われます。 これは、次のように書くことで上書きできます。

const balls: number[] = [1, 2 ,3];

さらに、タプル要素へのアクセスは、厳密なnullチェックで一貫して処理されます。 次の例では、厳密なnullチェックが有効になっている場合でも、現在nがnumberとして推測されていることに驚いています。

const balls: [number, number, number] = [1, 2 ,3];
const n = balls[100];

また、 .pushなどの配列ミューテーションメソッドは、ランタイムタイプがコンパイル時タイプと矛盾するように変更されるため、タプルタイプ定義に存在しないと予想されます。

@ buu700 TypeScript 3.0へようこそ： https ： //blogs.msdn.microsoft.com/typescript/2018/07/30/announcing-typescript-3-0/#richer -tuple-types

良い！ それは興味深いタイミングです。 リリースアナウンスを開いていましたが、まだ読んでいませんでした。 TypeScript（2.9）にやりたいことをさせるために、奇妙なキャスト（ (<(T|undefined)[]> arr).slice(-1)[0] ）を行う必要がある状況に遭遇した後にのみここに来ました。

この提案に物事を戻したかっただけです： https ：

これにより、私が経験したインデックス付きタイプの問題が修正されます。 それがデフォルトだったら素晴らしいのですが、それは現実の世界で多くのことを壊してしまうことを私は理解しています。

@mhegazy @RyanCavanaugh私の提案について何か考えはありますか？ https://github.com/Microsoft/TypeScript/issues/13778#issuecomment -406316164

私には、簡単な解決策があります。 これをチェックするフラグを有効にします。 次に、代わりに：

const array = [1, 2, 3];
for (var i =0; i< array.length; i++) {
    array[i]+=1; // array[i] is possibly undefined
}

あなたがやる：

const array = [1, 2, 3];
array.forEach((value, i) => array[i] = value + 1);

次に、ランダムインデックスアクセスを実行する場合、結果が未定義であるかどうかを確認する必要がありますが、列挙されたコレクションの反復中は確認する必要がありません。

私はまだこれが未解決の問題を抱えていることを正当化すると思います。

TypeScriptを初めて使用するプログラマーとして、厳密モードでオブジェクトにインデックスを付ける状況は直感的ではないことがわかりました。 私は、ルックアップの結果があることを期待しているだろうT | undefinedと同様に、 Map.get 。 とにかく、私は最近これに遭遇し、図書館で問題を開きました：

スクリーパー/ typed-screeps＃107

良い解決策がないように思われるので、私はおそらく今それを閉じるつもりです。 小さなユーティリティ関数を使用して、 T | undefined 「オプトイン」してみようと思います。

export function lookup<T>(map: {[index: string]: T}, index: string): T|undefined {
  return map[index];
}

ここでは、オブジェクトインデックス操作の戻りタイプとしてT | undefinedを明示的に設定するためのいくつかの提案がありましたが、それは機能していないようです。

const obj: {[key: string]: number | undefined} = {
  "a": 1,
  "b": 2,
};

const test = obj["c"]; // const test: number

これはVSCodeバージョン1.31.1です

あなたが持っていることを確認します@yawaramin strictNullChecksあなたで有効をtsconfig.json （もで有効になっているstrictフラグ）

ユースケースで長さが不明な配列に任意のインデックスを付ける必要がある場合は、undefinedを明示的に追加する価値があると思います（その安全性を「文書化」する場合のみ）。

const words = ... // some string[] that could be empty
const x = words[0] as string | undefined
console.log(x.length) // TS error

タプルは、既知の長さの小さな配列に対して機能します。 [string, string, string, string, string]省略形としてstring[5]ようなものがあるかもしれませんか？

オプションとしてこれを非常に支持します。 これは、特にstrictNullChecksフラグが有効になっている場合に、型システムの顕著な穴です。 JSではプレーンオブジェクトが常にマップとして使用されるため、TypeScriptはそのユースケースをサポートする必要があります。

関数パラメーターの配列破壊でこれに遭遇しました：

function foo([first]: string[]) { /* ... */ }

ここでは、 aはstring | undefined型であると予想しますが、そうでない限り、 stringです。

function foo([first]: (string | undefined)[]) { /* ... */ }

コードベースにforループが1つもないと思うので、tsconfigのコンパイラオプション（ strictIndexSignaturesという名前にすることができます）にフラグを追加して、この動作を切り替えたいと思います。私たちのプロジェクトのために。

これは私がこの問題を回避する方法です： https ：

良い回避策です。これがTypeScriptチームによって阻止されることを本当に望んでいます。

プログラマーが記述されたコードで仮定を行い、コンパイラーがそれが保存されていると推測できない場合、IMHOを沈黙させない限り、コンパイラー・エラーが発生するはずです。

この動作は、新しいオプションの連鎖演算子と組み合わせても非常に役立ちます。

今日、 Object.entries()を使用しているときに、マップで| undefinedを使用する際に問題が発生しました。

{[key: string]: string[]}でかなりよく説明されているインデックスタイプがありますが、可能なすべての文字列キーがインデックスで表されるわけではないという明らかな警告があります。 ただし、インデックスから検索した値を使用しようとしたときにTSがキャッチしなかったバグを作成しました。 未定義のケースを処理しませんでした。

そこで、推奨どおりに{[key: string]: string[] | undefined}に変更しましたが、これにより、 Object.entries()使用に問題が発生します。 TypeScriptは、（合理的に、型の指定に基づいて）インデックスに未定義の値が指定されたキーがあると想定するため、 Object.entries()を呼び出した結果に未定義の値が含まれる可能性があると想定します。

しかし、私はこれが不可能であることを知っています。 undefined結果を取得する必要があるのは、存在しないキーを検索することだけです。これは、 Object.entries()を使用するとリストされません。 したがって、TypeScriptを満足させるには、存在する本当の理由がないコードを作成するか、警告をオーバーライドする必要がありますが、これはやりたくないことです。

@RyanCavanaugh 、これに対するあなたの最初の返事はまだTSチームの現在の位置だと思いますか？ スレッドを読んだり、より強力なJSコレクションプリミティブを2、3年経験した場合に備えてチェックしたり、何かを変更してから厳密性を高めるために他のいくつかのオプションを導入したりすることはありません。

（そこにある例はまだ私にはやや説得力がありませんが、このスレッドはすでにすべての議論を行っています、別のコメントは何も変更しません）

誰かがlib.d.tsを変更し、自分のコードのすべてのダウンストリームブレークを修正し、全体的な差分がどのように見えるかを示して、これに何らかの価値提案があることを示したい場合は、そのデータを受け入れます。

@RyanCavanaughこれは私のコードベースからのいくつかのランタイムクラッシュが眠っているケースのいくつかです。 これが原因で本番環境でクラッシュが発生し、修正プログラムをリリースする必要があった場合があることに注意してください。

src={savedAdsItem.advertImageList.advertImage[0].mainImageUrl || undefined}

return advert.advertImageList.advertImage.length ? advert.advertImageList.advertImage[0].mainImageUrl : ''

birthYear: profileData.birthYear !== null ? profileData.birthYear : allowedYears[0].value,

upsellingsList.upsellingProducts[0].upsellingProducts[0].selected = true

const latitude = parseFloat(coordinates.split(',')[0])

const advert = Object.values(actionToConfirm.selectedItems)[0]
await dispatch(deactivateMyAd(advert))

この場合、 ArticleIDs extends articleNames[]は結果の値にundefinedを含むので面倒ですが、完全に定義されたサブセットのみを許可する必要があります。 articleNames[]代わりにReadonlyArray<articleNames>を使用すると、簡単に修正できます。

export enum articleNames {
    WEB_AGB = 'web_agb',
    TERMS_OF_USE = 'web_terms-of-use',
}
export const getMultipleArticles = async <ArticleIDs extends articleNames[], ArticleMap = { [key in ArticleIDs[number]]: CmsArticle }>(ids: ArticleIDs): Promise<ArticleMap> => {...}

全体として、実行時のクラッシュの可能性を防ぐために、この追加の型安全性が本当に必要です。

私はこのコメント＃11238（コメント）でもう少し推論に入りました

世界の2種類のキーについて考えてみてください。あるオブジェクトに対応するプロパティがあることを知っているキー（安全）と、あるオブジェクトに対応するプロパティがあることを知らないキー（危険）です。

次のような正しいコードを書くことで、最初の種類のキーである「安全な」キーを取得します。

for (let i = 0; i < arr.length; i++) {
  // arr[i] is T, not T | undefined

また

for (const k of Object.keys(obj)) {
  // obj[k] is T, not T | undefined

2番目の種類は、キーから「危険な」種類、ユーザー入力、ディスクからのランダムなJSONファイル、または存在する可能性があるが存在しない可能性のあるキーのリストなどから取得します。

したがって、危険な種類のキーとそれによるインデックスがある場合は、ここに| undefinedがあると便利です。 しかし、提案は「_危険な_キーを危険なものとして扱う」ではなく、「_すべての_キー、安全なものも危険なものとして扱う」です。 そして、安全な鍵を危険なものとして扱い始めると、人生は本当にひどいものになります。 あなたは次のようなコードを書きます

for (let i = 0; i < arr.length; i++) {
  console.log(arr[i].name);

TypeScriptは、 arr[i]がundefinedなる可能性があると不平を言っていますが、_ちょっと@＃％＃ingテストしただけです_。 今、あなたはこのようなコードを書く習慣を身につけます、そしてそれは愚かだと感じます：

for (let i = 0; i < arr.length; i++) {
  // TypeScript makes me use ! with my arrays, sad.
  console.log(arr[i]!.name);

または多分あなたはこのようなコードを書く：

function doSomething(myObj: T, yourObj: T) {
  for (const k of Object.keys(myObj)) {
    console.log(yourObj[k].name);
  }
}

TypeScriptは「ねえ、そのインデックス式は| undefinedかもしれないので、このエラーをすでに800回見たので、それを忠実に修正します。

function doSomething(myObj: T, yourObj: T) {
  for (const k of Object.keys(myObj)) {
    console.log(yourObj[k]!.name); // Shut up TypeScript I know what I'm doing
  }
}

しかし、あなたはバグを修正しませんでした。 あなたはObject.keys(yourObj) 、または多分myObj[k]を書くつもり

古い「このファイルを削除してもよろしいですか？」と思います。 ダイアログ。 ファイルを削除しようとするたびにそのダイアログが表示された場合、以前はdel押していたときに、 del y押すことをすぐに学び、重要なものを削除しない可能性が前にリセットされます-ダイアログベースライン。 代わりに、ファイルがごみ箱に移動していないときにファイルを削除しているときにのみダイアログが表示された場合は、意味のある安全性が得られます。 ただし、オブジェクトキーが安全かどうかはわかりません（また、可能性もありません）。そのため、「そのオブジェクトにインデックスを付けてもよろしいですか？」と表示します。 ダイアログを実行するたびに、すべてを表示しないよりも良いレートでバグを見つけることはできません。

私はファイル削除ダイアログのアナロジーに同意しますが、このアナロジーは、ユーザーに未定義またはnullの可能性があるものをチェックさせることにも拡張できると思います。したがって、この説明が正しい場合、この説明は実際には意味がありません。 strictNullChecksオプションは、同じ動作を引き起こします。たとえば、 document.getElementByIdを使用してDOMから要素を取得します。

しかし、そうではありません。多くのTypeScriptユーザーは、トレースが非常に難しいCannot access property X of undefinedエラーをスローする代わりに、これらのエッジケースを適切に処理できるように、コンパイラーがそのようなコードに関するフラグを立てることを望んでいます。

結局、これらの種類の機能を追加のTypeScriptコンパイラオプションとして実装できることを願っています。これが、ユーザーがTypeScriptを使用する理由であり、危険なコードについて警告されることを望んでいるためです。

配列やオブジェクトへの誤ったアクセスについて話すことは起こりそうにありませんが、この主張をバックアップするためのデータはありますか？ それとも、恣意的な腸の感覚に基づいているだけですか？

for (let i = 0; i < arr.length; i++) {
  console.log(arr[i].name);

TypeScriptの制御フローベースの型分析は、このケースが安全であり、 !必要としないことを認識するように改善される可能性があります。 人間がそれが安全であると推論できるのであれば、コンパイラもそうすることができます。
ただし、これをコンパイラに実装するのは簡単ではないかもしれないことを私は知っています。

TypeScriptの制御フローベースのタイプ分析は、このケースが安全であると認識するように改善される可能性があります

それは本当にできません。

declare function someFunc(arr: number[], i: number): void;
let arr = [1, 2, 3, 4];
for (let i = 0; i < arr.length; i++) {
  someFunc(arr, arr[i]);
}

この関数は、ループの2回目のパスでundefinedをsomeFuncに渡しますか？ someFuncで書くことができるものはたくさんあり、後でundefined表示されます。

これはどうですか？

declare function someFunc(arr: number[], i: number): void;
let arr = [1, 2, 3, 4];
let alias = arr;
for (let i = 0; i < arr.length; i++) {
  someFunc(alias, arr[i]);
}

@fabb別の例を挙げましょう：

`` `
$ノード

const arr = []
未定義
arr [7] = 7
7
arr
[<7つの空のアイテム>、7]
for（let i = 0; i <arr.length; i ++）{
... console.log（arr [i]）
...}
未定義
未定義
未定義
未定義
未定義
未定義
未定義
7
undefined```

あなたはどのように推論については、ここにいるので、@RyanCavanaugh item :: Tのためにarr :: T[]でfor (const item of arr) ... 、およびそれ以外の推測arr[i] :: T | undefinedいくつか使用している場合--strict-index ？ 私が気にかけているケースはどうですか、 obj[key] :: V | undefinedが、 Object.values(obj) :: V[]場合はobj :: { [key: string]: V }ですか？

@yawaraminスパース配列を使用している場合、 --strict-indexフラグはそれを修正します。 これはコンパイルします：

const arr = []
arr[7] = 7

for (let i = 0; i < arr.length; i++) {
    console.log(Math.sqrt(arr[i]));
}

@RyanCavanaughユーザーが配列に誤ってアクセスする傾向がある場所を示すことができる非常に一般的な例が1つあります。

const getBlock = (unitNumber: string): string => unitNumber.split('-')[0]

上記のコードは、 strictNullChecks下でコンパイラチェックに合格しないでください。 getBlockすると、 getBlock('hello')などの未定義が返されるため、このような場合は、アプリケーションを爆発させることなく未定義のケースを適切に処理できるように、raiseフラグをコンパイラーします。

また、これは、 arr.slice(-1)[0]を使用して配列の最後の要素にアクセスする、最初の要素arr[0]アクセスするなど、多くの一般的なイディオムにも当てはまります。

最終的には、爆発したアプリケーションを処理するのではなく、TypeScriptがそのようなエラーで私を悩ませてほしいと思っています。

この関数は、ループの2回目のパスで未定義をsomeFuncに渡しますか、それともそうではありませんか？ someFuncで記述できることはたくさんあり、後で未定義が表示されることになります。

@RyanCavanaughはい、JavaScriptは不変性には向いていません。 この場合、 !が必要であるか、 ReadonlyArray配列： someFunc(arr: ReadonlyArray<number>, i: number)いずれかが必要です。

@yawaraminスパース配列の場合、TypeScriptがタプルのように使用されていると推測できない限り、要素タイプにはおそらくundefinedを含める必要があります。 @danielnixonがリンクしたコード（https://github.com/microsoft/TypeScript/issues/13778#issuecomment-536248028）では、タプルも特別に扱われ、返される要素タイプにundefinedが含まれていません。コンパイラは、設定されたインデックスのみがアクセスされることを保証するためです。

これは意識的な決定です。 このコードがエラーになるのは非常に面倒です。

var a = [];
for (var i =0; i< a.length; i++) {
    a[i]+=1; // a[i] is possibly undefined
}

ねえ、私はその構文を認識しています。 私はおそらく年に一度、このようなループを書きます！

私が実際に配列にインデックスを付けるほとんどの場合、後で実際にundefinedをチェックしたいことがわかりました。

この特定のケースを扱いにくくすることへの恐れは誇張されているようです。 要素を反復処理するだけの場合は、 for .. of使用できます。 何らかの理由で要素インデックスが必要な場合は、 forEach使用するか、 entries繰り返し処理します。 一般に、インデックスベースのforループが本当に必要になることは非常にまれです。

現状を維持したい理由がもっとあるなら、私はそれらを見たいのですが、それにもかかわらず：これはシステムの不整合であり、それを修正するためのフラグを持っていることは多くの人に高く評価されているようです。

みなさん、ここでの議論の多くは
持っていました。 パッケージの所有者は、その理由と
これらの議論のほとんどはすでに検討されています。 彼らが対処することを計画している場合
これ、私は彼らがそれを知らせると確信しています。 それ以外は、これはないと思います
スレッドは本当に生産的です。

11:59時金、2019年10月25日にはbrunnerh [email protected]書きました：

これは意識的な決定です。 このコードが
エラーになる：

var a = []; for（var i = 0; i <a.length; i ++）{
a [i] + = 1; // a [i]はおそらく未定義です
}

ねえ、私はその構文を認識しています。 私はおそらく年に一度、このようなループを書きます！

私が実際に配列にインデックスを付けるほとんどの場合、私は
実際に後で未定義をチェックしたい。

この特定のケースを扱いにくくすることへの恐れは誇張されているようです。
..ofに使用できる要素を繰り返し処理するだけの場合。 もしも
何らかの理由で要素インデックスが必要な場合は、forEachを使用するか、繰り返します
エントリ。 一般的に、あなたが本当に必要とすることは非常にまれです
インデックスベースのforループ。

現状を望む理由がもっとあるなら、私は
それらを見たいが、関係なく：これはシステムの不整合です
そしてそれを修正するための旗を持っていることは多くの人に高く評価されているようです。

—
あなたがコメントしたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/microsoft/TypeScript/issues/13778?email_source=notifications&email_token=ACAJU3DQ7U6Y3MUUM26J4JDQQM62XA5CNFSM4C6KEKAKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN
または購読を解除する
https://github.com/notifications/unsubscribe-auth/ACAJU3EWVM3CUFG25UF5PGDQQM62XANCNFSM4C6KEKAA
。

パッケージの所有者からの動きはないかもしれませんが、コミュニティからの継続的なフィードバックは、この問題を回避するためのより優れたツールに対する需要がまだあることを示しているため、依然として価値があると思います。

@brunnerh同意します。最近では、パフォーマンスチューニング用でない限り、 forループを使用する必要はありません。パフォーマンスチューニングは、ほとんどの場合マップを変更するため、会社のコードベースで0％の確率で発生します。 / filter / reduce to for loopがパフォーマンスを向上させることはめったにありません。本当の原因は、常に非効率的なロジック、ネットワークの問題、およびデータベース接続に関するものです。

まだ誰もas constについて話していないことに驚いています。

const test = [1, 2, 3] as const;

(test[100]).toFixed(5);
// Tuple type 'readonly [1, 2, 3]' of length '3' has no element at index '100'.

より一般的には、この問題の最初のメッセージとは正確には関連していませんが、過去数か月間、次の防御的なプログラミングパターンを使用してきましたが、うまく機能しました（私にとって）

const xs: Array<number | undefined> = [1,2,3];

// for objects but kind of related as well
Record<string, User | undefined>

interface Something {
  [key: string]: User | undefined
}

短い表記（ ? ）はありませんが、問題ないと思います。 値が定義されているかどうかわからない可能性があることをコンパイラーに自分で伝えるのは問題ありません。

@martpie as constは、使用できるのであれば素晴らしいです。

Array<T | undefined>使用したくない理由は少なくとも2つあります。

1. 配列を使用するたびに覚えておかなければならないことがもう1つあります。 また、暗黙の入力を使用することはできなくなりました。これは便利です。
2. forEach 、 map 、およびfilterの署名を変更します。これらは、要素引数としてundefinedを渡しません（インデックスが明示的にそのように設定されている場合を除く）。 扱いにくい機能をどれだけ使用するかによって異なります。

また、これがeslint / typescriptで多くの誤検知を引き起こすという点でチャイムを鳴らしたいと思います。

const a: string[] = [];
const foo = a[1000];
if (foo) { // eslint says this is an unnecessary conditional
  console.log(foo.length);
}

Eslintは、fooがnullになることはないため、これが不要なチェックであるとタイプから（正しく）推測します。 したがって、配列から返されるものに対してnullチェックを行うことを意識的に覚えておく必要があるだけでなく、eslint無効化行を追加する必要もあります。 そして、このようなforループの外側にあるものにアクセスすることは、配列アクセスを行う唯一の方法です。なぜなら（最近のほとんどのTS開発者のように）、配列をループするときにforEach / map / filter / etc関数を使用するからです。

strictがtrueの場合、デフォルトでtrueに設定されている新しいコンパイラフラグが必要だと本当に思います。人々がそれを気に入らない場合は、オプトアウトできます。 とにかく、最近のバージョンでは、新しい重大な厳密なコンパイラチェックを追加しました。

これは、型システムの障害である、最近のメモリで見た_only_ランタイムprodバグの原因である可能性が非常に高いです。

現在利用可能なオプションの連鎖演算子の人間工学を考慮して、フラグを介してこの動作を利用可能にしないという決定を再検討する時が来たのではないでしょうか。

サーバーからThing配列を取得し、配列の最後のThingを表示する必要がある場合、よくあることは、配列が実際には空であり、プロパティにアクセスしていることです。そのThingでアプリがクラッシュします。

例：

// `things` is `Thing[]`, but is empty, i.e., `[]`
const { things } = data; 

// We are accessing `things[-1]`, which is obviously `undefined`, 
// but TypeScript thinks `latestThing` is a `Thing`
const latestThing = things[things.length - 1];

// TypeError: Cannot read property 'foo' of undefined
return latestThing.foo; 

これはAPIの設計の問題かもしれませんが、配列内の何かにアクセスするときに、実際には存在しない可能性があることをTSが理解する必要があるように感じます。

編集： 「私が取り組んでいるチームによって作成されたAPI」のように「私たちのAPI」を意味したことを明確にしたいだけです

はい、誰もがそれが非常に悪い設計上の決定であり、TSが完全に安全ではなかった遠い時代に現代的なものであることにほぼ同意しています。

回避策として、私は小さな汚いハックを使用します。 package.jsonに簡単なポストインストールスクリプトを追加するだけです。

{
...
  "scripts": {
    "postinstall": "sed -i 's/\\[n: number\\]: T;/[n: number]: T | undefined;/g' node_modules/typescript/lib/lib.es5.d.ts",
    ...
  },
...
}

もちろん、それはウィンドウズでは機能しませんが、それは何もないよりはましです。

これに隣接して実行される他のすべての問題はここでリダイレクトされるように見えるので、これが質問するのに最適な場所であると思います：オプションのインデックス署名の省略構文はテーブルから外れていますか？ @martpieが指摘しているように、 interface Foo { [k: string]?: Bar; }より人間工学的でないinterface Foo { [k: string]: Bar | undefined; }を書く必要があります。

?:オペレーターのサポートを受けることはできますか？ そうでない場合は、なぜですか？ つまり、人間工学的な利点は、単一のプロパティ定義の機能を追加するのに十分でした。インデックス署名には「十分に役立つ」のではないでしょうか。

type Foo = { [_ in string]?: Bar }も機能します。 それほどきれいではありませんが、かなり簡潔です。 必要に応じて、独自のDict型を作成することもできます。 ただし、 ?:拡張子に異議を唱えることはありません

これは、「Javascript：TheBadParts」の講演の1つのように感じ始めています。

ts type Foo1 = { [_ in string]?: Bar } // Yup type Foo2 = { [_: string]?: Bar } // Nope interface Foo3 { k?: Bar } // Yup interface Foo4 { [_: string]?: Bar } // Nope

タイプシグネチャにT | undefinedを使用することは、実際には役に立ちません。 インデックス演算子[n]がT|undefined型になるようにする方法が必要ですが、たとえば配列でmapしても、 T|undefinedは得られませ

@radix配列の実際の関数については、すべてが正しい型を出力する独自の型定義を持っているため、これが問題になるとは思いません。例： map ： https ：

| undefinedコンストラクトが実際のエクスペリエンスのリグレッションを引き起こす唯一の一般的なコードの使用法は、 for ... ofループ内です。 残念ながら（この問題の観点から）、これらはかなり一般的な構成です。

@riggs interface Array<T> { }に[index: number]: T | undefined interface Array<T> { }持たせることについて話していると思いますが、 @ radioxは、現在の推奨事項と思われるもの、つまりArray<T | undefined>を使用することについて話している可能性があります。あなた自身のコード。

後者はいくつかの理由で悪いです。特に、他のパッケージの型を制御できないということですが、前者にはいくつかの問題もあります。つまり、配列にundefinedを割り当てることができるということです。安全なケースであることがわかっている場合でも、 undefinedを提供します。 🤷‍♂️

ああ、はい、私の誤解です。 確かに、私は定義[index: number]: T | undefined使用についてのみ言及していました。 タイプをArray<T | undefined>として定義することは、解決するよりも多くの問題を引き起こすひどい回避策であることに完全に同意します。

lib.es5.d.tsを上書きする適切な方法はありますか、それともインストール後のスクリプトが最善の方法ですか？

@ NICU-chiciuc https://www.npmjs.com/package/patch-package全く一緒異端者のツールボックスに収まるhttps://www.npmjs.com/package/yalc ✌️

lib.es5.d.tsをオーバーライドするための適切な方法はありますか、それともインストール後のスクリプトが最善の方法ですか？

私たちのプロジェクトでは、1）typescriptのデフォルトの型定義にまだ含まれていない組み込みAPIの型定義を追加するために使用するglobal.d.tsファイルがあります（たとえば、ブラウザ間で絶えず変化し、一貫性がないWebRTC関連のAPI ）および2）typescriptのデフォルトの型定義の一部をオーバーライドします（たとえば、 anyではなくunknownを含む配列を返すようにObject.entriesの型をオーバーライドします）。

このアプローチを使用してtypescriptの配列型をオーバーライドしてこの問題を解決できるかどうかはわかりませんが、試してみる価値があるかもしれません。

上記は、宣言のマージによって目的の結果が得られる場合に機能しますが、単純化するためにインターフェイスと交差しますが、ここでは制限の少ないオプションが必要です。

代わりに、使用しているすべてのlib.*.d.tsファイルをプロジェクトにコピーして貼り付け、 tsconfig.jsonのfilesまたはincludeに含めて、それらを編集することもできます。あなたが望むものに。 /// <reference no-default-lib="true"/>が含まれているので、他の魔法は必要ありませんが、依存関係にある/// <reference lib="..."/>を削除する必要があるかどうかはわかりません。 もちろん、これは明らかな保守性の理由から悪いことです。

@butchlerこのアプローチも使用していますが、他のいくつかの配列関数（タイプガード付きのfilter ）を正常にオーバーライドしたにもかかわらず、インデックス演算子をオーバーライドすることはできなかったようです。

インデックス演算子をオーバーライドするという奇妙なケースがあります。

function test() {
  const arr: string[] = [];

  const [first] = arr;
  const zero = arr[0];

  const str1: string = first;
  const str2: string = zero;
}

2番目の割り当ては（当然のことながら）エラーになりますが、最初の割り当てはエラーになりません。
さらに奇妙なことに、構造化されていないときにfirstカーソルを合わせると、タイプがstring | undefinedあることが示されますが、割り当てられているときにカーソルを合わせると、タイプがstringあることが示されます。

配列の破棄に別の型定義はありますか？

インデックスの欠落に関連するエラーが私のコードのバグの頻繁な原因であるため、これに対する解決策を探しています。

{ [index: string]: string | undefined }ようなタイプを指定することは、 undefined値が含まれないObject.values(x).forEach(...)ようなイテレーターの入力を台無しにするため、解決策ではありません。

someObject[someKey]実行した後に未定義をチェックしない場合にTypeScriptがエラーを生成するのを見たいのですが、 Object.values(someObject).forEach(...)実行した場合はそうで

@tobico https://github.com/microsoft/TypeScript/issues/13778#issuecomment -536248028

@danielnixonこれは解決策ではなく、回避策です。 あなたや他の開発者が同じ目的のために言語の組み込みツールを誤って使用することを妨げるものは何もありません（あなたがそれをそれと呼ぶことさえできれば）。 つまり、私はこのようなものにfp-tsを使用していますが、この問題はまだ有効であり、修正する必要があります。

@RyanCavanaughからの議論を次のようにたどることができますが：

for (let i = 0; i < arr.length; i++) {
  // TypeScript makes me use ! with my arrays, sad.
  console.log(arr[i]!.name);

私はそれにいくつかの短い考えを落とします。 中核となるのは、TypeScriptは開発をより安全にすることです。 TypeScriptの最初の目標を覚えておくに

1.エラーである可能性が高い構成を静的に識別します。

コンパイラーを見ると、型推論の背後にすでにいくつかの魔法があります。 特定のケースでは、本当に言い訳は「この構成で正しいタイプを推測できない」であり、それはまったく問題ありません。 時間の経過とともに、コンパイルで型を推測できないケースはますます少なくなっています。 言い換えれば、私にとっては、より洗練された型推論を取得するのは時間の問題です（そしてこれに時間を費やす）。

技術的な観点から、次のような構成になります。

const x = ['a', 'b', 'c']
console.log(x[3]) // type: string, reality: undefined

TypeScriptの最初の目標を破ります。 しかし、TypeScriptがより正確な型を知っている場合、これは起こりません。

const x = ['a', 'b', 'c'] as const
console.log(x[3]) // compile error: Tuple type 'readonly ["a", "b", "c"]' of length '3' has no element at index '3'.ts(2493)

実用的な観点からは、これはトレードオフyetです。 この問題と複数のクローズされた問題は、この変更に対するコミュニティの高い需要があることを示しています。ATM238の賛成票と2つの反対票。 もちろん、上記のforループが「正しい」タイプを推測しないのは残念ですが、まあ、ほとんどの賛成者は!と新しい?で生きることができると確信しています。注意の兆候と安全な場合にそれを強制します。 しかし、反対側では、「危険な」アクセスで適切なタイプを取得します。

これは大きなコードベースにとって非常にデリケートな変更であることに同意するため、ここで提案されているように、構成プロパティに投票

これは提案された解決策ではなく、単なる実験です。TypeScriptを使用する既存のプロジェクトでnode_modules内のlib.es5.d.tsを変更して、コンパイラが_did_された場合の結果を確認しました。このためのオプション。 ArrayとReadonlyArray ：

interface ReadonlyArray<T> {
  ...
  [n: number]: T | undefined; // was just T
}

interface Array<T> {
  ...
  [n: number]: T | undefined; // was just T
}

これは非常に大規模なプロジェクトであるため、数百のタイプエラーが発生しました。 私はそれらのいくつかを調べて、私が遭遇する問題の種類と、このためのコンパイラオプションがある場合にそれらを回避するのがどれほど難しいかについてのアイデアを得ました。 これが私が遭遇した問題のいくつかです：

1. これにより、コードベースだけでなく、依存関係の1つであるio-tsでも型エラーが発生しました。 io-tsを使用すると、独自のコードで使用する型を作成できるため、このオプションを独自のコードベースにのみ適用し、io-tsの型にも適用することはできないと思います。 つまり、コンパイラオプションとしてのみ導入された場合でも、このオプションを使用するには、io-tsおよびおそらく他のいくつかのライブラリを更新する必要があります。 最初は、これをコンパイラオプションにすることで物議を醸すことが少なくなると思いましたが、このオプションを使用することを選択した人が、さまざまなライブラリ作成者に非互換性について不平を言い始めた場合、単にTS4.0であるよりもさらに物議を醸す可能性があります。変化を壊す。

2. 時々、未定義の可能性を排除するために、いくつかのタイプガードを追加する必要がありました。 これは必ずしも悪いことではなく、この提案の要点の一種ですが、完全を期すために言及しているだけです。

3. for (let i = 0; i < array.length; i++)ループ内で、任意のArray<T>ループしているタイプエラーが発生しました。 T自体にundefinedが含まれている可能性があるため、タイプガードを追加してundefinedをチェックすることはできませんundefined 。 私が考えることができる唯一の解決策は、A）タイプアサーションを使用するか、 @ts-ignoreを使用してタイプエラーを消音するか、B）代わりにfor-ofループを使用することでした。 個人的には、これがそれほど悪くないとは思いませんが（for-ofループを使用して配列を反復処理する方が良い場合はおそらくほとんどありません）、物議を醸す可能性があります。

4. 既存のコードがすでに.lengthの値について何らかのアサーションを作成してから、配列内の要素にアクセスしている場合が多くあります。 これらは.lengthチェックにもかかわらずタイプエラーを引き起こすようになったので、 .lengthチェックに依存しないようにコードを変更するか、冗長な!== undefinedチェックを追加する必要がありました。 TypeScriptが.lengthチェックの使用を許可して、 !== undefinedチェックの必要性を回避できれば本当に素晴らしいでしょう。 ただし、実際に実装するのは簡単ではないと思います。

5. 一部のコードは、 A[number]を使用して、ジェネリック配列型の要素の型を取得していました。 ただし、これでTだけでなくT | undefined返されるようになり、他の場所でタイプエラーが発生しました。 私はこれを回避するためにヘルパーを作りました：

   type ArrayValueType<A extends { [n: number]: unknown }> = (
     A extends Array<infer T> ? T :
     A extends ReadonlyArray<infer T> ? T :
     A[number] // Fall back to old way of getting array element type
   );
   

   しかし、移行を容易にするこのヘルパーを使用しても、これは依然として大きな重大な変更です。 おそらく、TypeScriptには、この問題を回避するためにA[number]ある種の特殊なケースがある可能性がありますが、可能であれば、そのような奇妙な特殊なケースを回避するとよいでしょう。

私は数百のタイプエラーのほんの一握りを経験しただけなので、これはおそらく非常に不完全なリストです。

この問題の修正に関心のある他の人にとっては、いくつかの既存のプロジェクトで同じことを試して、発生した他の問題を共有することが役立つ場合があります。 うまくいけば、特定の例が実際にこれを実装しようとする人にいくつかのガイダンスを提供することができます。

@butchlerこれらの問題のいくつかにも遭遇し、 something[i]をsomething(i)として表示し始めました。つまり、 if (Meteor.user() && Meteor.user()._id) {...}ようなものを使用することはできないので、使用しません。配列の索引付けにこのアプローチがあることを期待します。 まず、配列から調べたい値を取得する必要があります。 私が言おうとしているのは、長さプロパティをチェックし、それに基づいて何らかのアサーションを行うことを理解するためにTSに依存することは、型システムに過度のストレスをかける可能性があるということです。 私が移行を延期した理由の1つは（あなたが言ったように、他のいくつかのライブラリにもエラーがあるという事実を除いて）、配列の非構造化がまだ正しく機能しておらず、非構造化された値がT | undefinedはないことですがT （他のコメントを参照）。
それ以外は、 lib.es5.d.tsオーバーライドするのが良いアプローチだと思います。 将来変更される場合でも、変更を元に戻してもエラーは追加されませんが、一部のエッジケースがすでにカバーされていることを確認できます。
react一部のタイプ定義を変更するために、すでにpatch-package使用を開始しており、このアプローチは問題なく機能しているようです。

また、これらの問題のいくつかに遭遇し、something [i]をsomething（i）として表示し始めました。つまり、if（Meteor.user（）&& Meteor.user（）._ id）{のようなものを使用することはできません。 ...}なので、配列のインデックス作成にこのアプローチを使用することは期待していません。 まず、配列から調べたい値を取得する必要があります。

ええ、私も実験を試みていたときにこのアプローチを使用することになりました。 たとえば、以前は次のように記述されたコード：

if (array[i]) {
  array[i].doSomething(); // causes a type error with our modified Array types
}

次のようなものに変更する必要がありました：

const arrayValue = array[i]
if (arrayValue) {
  arrayValue.doSomething();
}

私が言おうとしているのは、長さプロパティをチェックし、それに基づいて何らかのアサーションを行うことを理解するためにTSに依存することは、型システムに過度のストレスをかける可能性があるということです。

おそらく本当です。 実際に関するアサーションに依存して自動的に再書き込みコードのcodemod記述する方が簡単かもしれません.length活字スマートに十分な程度の表明に基づいてタイプの詳細を推測できるようにすることよりも、他のいくつかのアプローチを使用することを.length 😛

将来変更される場合でも、変更を元に戻してもエラーは追加されませんが、一部のエッジケースがすでにカバーされていることを確認できます。

これは良い点です。 インデックスタイプにundefinedを含めることは大きな変化ですが、反対方向に進むことは大きな変化ではありません。 T | undefined取得を処理できるコードは、変更なしでTも処理できるはずです。 これは、たとえば、コンパイラフラグがあった場合に、ライブラリを更新してT | undefinedケースを処理し、そのコンパイラフラグが有効になっていないプロジェクトで引き続き使用できることを意味します。

配列を無視し、しばらくの間Record<string, T>に焦点を当てると、私の個人的なウィッシュリストは、書き込みはTのみを許可しますが、読み取りはT|undefinedなる可能性があるということです。

declare const obj : Record<string, T>;
declare const t : T;
obj["k"] = t; //ok
obj["k"] = undefined; //error, undefined not assignable to T

//T|undefined inferred,
//since we don't know if "k2" is an "ownProperty" of obj
const v = obj["k2"];

上記を人間工学的にする唯一の方法は、ある種の依存型と依存型ガードです。 それらがないため、この動作を追加すると、あらゆる種類の問題が発生します。

//Shouldn't just be string[]
//Should also be something like (keyof valueof obj)[],
//A dependent type
const keys = Object.keys(obj);

配列に戻ると、問題は、配列のインデックス署名がRecord<number, T>と同じ意図を持っていないことです。

したがって、次のようなまったく異なる依存型ガードが必要になります。

for (let i=0; i<arr.length; ++i) {
  //i is not just number
  //i should also be something like keyof valueof arr 
}

したがって、配列のインデックス署名は実際にはRecord<number, T>はありません。 Record<(int & (0 <= i < this["length"]), T> （範囲と数値に裏打ちされた整数型）のようなものです

したがって、元の投稿では配列についてのみ説明していますが、タイトルは「ちょうど」 stringまたは「ちょうど」 numberインデックス署名を示唆しているようです。 そして、それらは2つのまったく異なる議論です。

TL; DR元の投稿とタイトルは異なることについて話し、どちらを実装するかは依存型に大きく依存しているように見えます（ha）。

forEach 、 map 、 filterなどの関数が存在することを考えると（そして私見の方がはるかに望ましい）、TSチームが推論エンジンを大幅に複雑にすることはないと思います。通常のforループを使用した配列のループをサポートします。 それを成し遂げようとすると、予想外の複雑さが多すぎるように感じます。 たとえば、 iは定数ではないため、ループ内で誰かがiの値を変更するとどうなりますか？ 確かに、それはエッジケースですが、（うまくいけば）直感的な方法で処理する必要があるものです。

ただし、上記のコメントが示しているように、インデックス署名の修正は比較的簡単なはずです。

4.既存のコードがすでに.lengthの値について何らかのアサーションを作成してから、配列内の要素にアクセスしている場合が多くあります。 これらは.lengthチェックにもかかわらずタイプエラーを引き起こすようになったので、 .lengthチェックに依存しないようにコードを変更するか、冗長な!== undefinedチェックを追加する必要がありました。 活字体は何とか使用可能性があれば、それは本当にいいだろう.lengthする必要性を避けるためにチェック!== undefinedチェックを。 ただし、実際に実装するのは簡単ではないと思います。

@butchler
好奇心から、固定数でアクセスするのではなく、変数を変更してアクセスするものはいくつありますか？ 後者の場合、おそらく配列をタプルとして使用しているため、TSは配列の長さを追跡します。 配列をタプルとして頻繁に使用している場合は、実際のタプルとして配列を再入力すると、エラーの量がどのようになるのか興味があります。

配列をタプルとして頻繁に使用している場合は、実際のタプルとして配列を再入力すると、エラーの量がどのようになるのか興味があります。

配列リテラルにas constを追加して変数の型をタプルに変換するだけで、型エラーを修正した1つのケースに遭遇しました。 数百のエラーのうち約10のエラーしか調べていないので、コードベースでそれがどれほど一般的であるかはまったくわかりません。

今日もこれで問題が発生しました。
計算されたインデックスを介して配列からアクセスしています。 そのインデックスは範囲外である可能性があります。
したがって、コードには次のようなものがあります。

const noNext = !items[currentIndex + 1];

これにより、 noNextはfalseとして定義されます。 どちらが間違っています。 それは本当かもしれません。
また、 itemsをArray<Item | undefined>として定義したくないのは、それが間違った期待を与えるからです。
インデックスが存在する場合、 undefinedあってはなりません。 ただし、間違ったインデックスを使用している場合、それは_is_ undefinedです。
確かに、上記はおそらく、代わりに.lengthチェックを使用するか、 noNextをbooleanとして明示的に定義することで解決できます。
しかし、結局、これはTypeScriptを使い始めてから気になり、 | undefinedがデフォルトで含まれていない理由がわかりませんでした。

ほとんどの場合typescript-eslintを使用することを期待しているので、値を使用する前に、インデックス付け後に値をチェックする必要があることを強制できるルールはありますか？ これは、TSからのサポートが実装される前に役立つ場合があります。

それが誰かに興味があるかもしれない場合に備えて。 以前のコメントでは、私は、パッチ適用のアプローチと述べArrayでインデックス化の定義をlib.es5.d.ts 、それは変化の影響を受けていなかったようだったので、配列の非構造上のいくつかの奇妙な行動を持っています。 依存するようだtargetでオプションtsconfig.jsonとそれがあるとき、それは正常に動作するes5 https://github.com/microsoft/TypeScript/issues/37045（ ）。

私たちのプロジェクトでは、 noEmitオプションを使用しており、変換はmeteorによって処理されるため、問題はありません。 しかし、それが問題になる可能性のあるプロジェクトの場合、機能する可能性のある解決策はsafe-array-destructuring （https://github.com/typescript-eslint/typescript-eslint/pull/1645）です。
これはまだドラフトであり、TypeScriptコンパイラで問題全体が修正されるときには価値がない可能性がありますが、役立つと思われる場合は、 typescript-eslintルールPRで懸念事項や改善点に自由に対処してください。

残念ながら、PRでeslintを使用した修正では、タプルのみがサポートされ、配列はサポートされません。 私がこれに関して持っている主な問題と主な影響は、アレイの破壊にあります。

const example = (args: string[]) => {
  const [userID, nickname] = args
}

この問題全体は、私が同意しない側に進んだと思います。 forEach、mapなどの内部で強制的なチェックを行うべきではないと思います...また、可能な場合はforのすべての使用を避けようとしているので、これを避ける理由は私にはあまり意味がありません。 それでも、アレイの破壊をサポートするには、これが非常に重要だと思います。

まあ、それは配列の破壊に対してエラーになるだけなので、インデックスを使用してそれを行う必要があります。

でも悪くないですか？ アレイの破壊は驚くべき機能です。 問題は、入力が正確でないことです。 この機能を無効にすることは、実際には良い解決策ではありません。 私の意見では、インデックスの使用はコードが醜く（読みにくく、理解しにくい）、エラーが発生しやすくなっています。

それはもっと醜いですが、それは開発者に要素が定義されているかどうかをチェックすることを強制します。 もっとエレガントな解決策を考え出そうとしましたが、これが最も欠点の少ないもののようです。 少なくとも私たちのユースケースでは。

@caseyhowardこの号で前述したように、これにより、さまざまなArray.prototype関数で望ましくない動作が発生します。

x.forEach( (i: string) => { ... } )  // Error because i has type string | undefined

これは、array.prototype関数で修正する必要はありません。 これは、アレイの破壊にとって大きな問題です。

今日もこれに出くわした。 私はまだ正しい妥協点はこれだと思います、それについて私はいくつかのフィードバックを得たいと思います。

この問題の別の使用例—typescript-eslintを使用してno-unnecessary-conditionを有効にすると、この問題が発生しました。 以前は、インデックスによって配列にアクセスしてそのインデックスの要素に対して何らかの操作を行う場合、 array[i]?.doSomething()ように、オプションのチェーンを使用して、インデックスが定義されていることを確認します（インデックスが範囲外の場合）。 no-unnecessary-condition 、オプションの連鎖が不要であるとフラグを立て（typescriptによると、型はnull許容ではないため）、autofixはオプションの連鎖を削除し、配列がでアクセスするときにランタイムエラーを引き起こします。インデックスi実際には未定義です。

この機能がないと、多次元配列を扱っているため、アプリケーションが非常にバグになりました。 xs[i]?.[j]代わりにxs[i][j] xs[i]?.[j]を使用して要素にアクセスすることを常に忘れないでください。また、明示的にキャストする必要があります。型の安全性を確保するためにconst element = xs[i]?.[j] as Element | undefinedようなアクセスされた要素。

これに遭遇したのは、Typescriptでの私の最初の大きなwtfでした。 それ以外の言語は非常に信頼性が高く、これは私を失望させ、配列アクセスに「as T | undefined」を追加するのは非常に面倒です。 提案の1つが実装されるのを見たいです。

はい、ここでも同じです。 型安全性を持たせるために（ | undefined ）を持つ独自の型を展開することを余儀なくされました。 主にオブジェクトアクセス用ですが（おそらくそれは別の未解決の問題です）、同じロジックが配列インデックスへのアクセスにも適用されます。

問題をリンクしたり、例を示したりできますか？

2:41キリルGroshkovで水曜日、2020年4月29日には[email protected]
書きました：

はい、ここでも同じです。 それは私たちに（|
未定義）型安全性を持つこと。 主にオブジェクトアクセス用です（おそらくそれは
別の未解決の問題）が、同じロジックが配列インデックスへのアクセスに適用されます。

—
あなたがコメントしたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/microsoft/TypeScript/issues/13778#issuecomment-621096030 、
または購読を解除する
https://github.com/notifications/unsubscribe-auth/AAAGFJJT37N54I7EH2QLBYDRO7Y4NANCNFSM4C6KEKAA
。

@alangpierce

有望と思われるアイデアの1つは、インデックス署名を定義するときに?:使用して、通常の使用では値が欠落することがあることを示すことができるとしたらどうでしょうか。 上記の| undefinedように動作しますが、厄介な欠点はありません。 明示的なundefined値を禁止する必要があります。これは、通常の?:との違いだと思います。

これは正しい方向を指し示す興味深いアイデアです。 ただし、ロジックを逆にします。デフォルトの場合は、インデックス署名に| undefined含まれている必要があります。 コードで未定義のケースが発生しないことをコンパイラーに通知する場合（したがって、無効なキーにアクセスすることはありません）、次のように署名に!:を追加できます。

type AlwaysDefined = {[key: string]!: string};
const t: AlwaysDefined = {};

t['foo'] // Has type string

!:がないデフォルトのケースは、私たちが知っているように見えますが、より安全です。

type MaybeUndefined = {[key: string]: string};
const t: MaybeUndefined = {};

t['foo'] // Has type string | undefined

そうすれば、デフォルトで安全性が確保され、同時にundefinedを明示的に含める必要がなくなり、誤ってundefinedを書き込むことができます。

それがすでに提案されている場合は申し訳ありませんが、私はこのスレッドのすべてのコメントを読むことができませんでした。

一般的に、現在のデフォルトの動作は、TypeScriptを使用するときにユーザーが期待するものではないと本当に思います。 特にコンパイラがこれと同じくらい簡単にエラーをキャッチできる場合は、後悔するよりも安全である方がよいでしょう。

index.d.tsをプロジェクトで機能させることができず、実際に処理したくありませんでした。

タイプガードを強制するこの小さなハックを作成しました。

 const firstNode = +!undefined && nodes[0];

タイプは0 | Tになりますが、それでも機能します。

const firstNode = nodes?.[0]機能しませんか？

@ricklove単に1よりも+!undefinedを好んだ理由は何ですか？

const firstNode = nodes?.[0]機能しませんか？

いいえ、typescriptは（誤って、私の意見では）それをオプションとして扱いません（＃35139を参照）。

Flowのドキュメントによると、インデックス署名の動作は現在TypeScriptの場合と同じです。

オブジェクトタイプにインデクサープロパティがある場合、実行時にオブジェクトのスロットに値がない場合でも、プロパティアクセスには注釈付きタイプがあると見なされます。 配列の場合と同様に、アクセスが安全であることを確認するのはプログラマーの責任です。

var obj: { [number]: string } = {};
obj[42].length; // No type error, but will throw at runtime

したがって、この懸念では、TSとFlowの両方で、コンパイラがキーを支援するのではなく、未定義のキーについて考える必要があります:(

コンパイラがユーザーがこれらの種類のバグを作成するのを防いだ場合、TSの利点になります。 このスレッドのすべてのコメントを読むと、ここの大多数はこの機能を望んでいるようです。 TSチームはまだ100％反対していますか？

これを除いて、TSが未定義のメンバーへのアクセスを防ぐために最善を尽くしているのはばかげているようです。 これは、私がコードベースで修正してきた最も一般的なバグです。

[ここに＃3847​​0から議論を移す]
なぜこれが配列にとって実用的でないのかについてのすべての議論を受け入れる。
タプルについては、これに確実に対処する必要があると思います。

// tuple 
var str = '';
var num = 100
var aa = [str, num] as const

// Awesome
var shouldBeString = aa[0] // string
var shouldBeNumber = aa[1] // number
var shouldError = aa[10000]; // type error

// Not so awesome 
var foo = aa[num] // string | number

fooをstring | number | undefinedませんか？

これをタプルに与えることは大多数のユーザーに影響を与えるべきではなく、影響を与えるユーザーはstrictNullChecks有効にし、配列を定数として宣言する必要があります...
彼らは明らかにより厳しいタイプの安全を探しています。

これらを助けることもできます

var notString1 = aa[Infinity]; // no error, not undefined
var notString2 = aa[NaN]; // no error, not undefined

numberがNaNになり、タプルからundefinedを返したため、元々ランタイムエラーが発生していました。
これらはすべてタイプセーフでした

タプルが本当に違うかどうかはわかりません。 それらはRESTタイプ（たとえば[str, ...num[]] ）に対応する必要があり、技術的にはaa[Infinity]は完全に有効なJavascriptであるため、それらの特殊なケースを作成するのは複雑になることがわかりました。

あなたの投稿はまた、インデックスリターンを未定義として扱うためのサポートを得た場合にどのようになるかについて考えさせられました。 あなたの例のように、 aa[num]実際にstring | number | undefined場合、インデックスが範囲内にとどまることがわかっていても、 for (let i = 0; i < 2; i++) { foo(aa[i]!); }と書く必要がありますか？ 私にとって、厳密なnullチェックが私が書いたものにフラグを立てるとき、私は最初に物事をよりよく入力するか、ランタイムガードを使用することによってそれを修正できるようにしたいです-null以外のアサーションに頼る必要がある場合、私は通常私の側の失敗としてそれを見てください。 しかし、この場合、私はそれを回避する方法がわかりません、そしてそれは私を悩ませます。

tuple[number]常にT | undefinedと入力されている場合、インデックスが正しくバインドされていることがわかっている場合をどのように処理しますか？

@ thw0rted Typescriptで「クラシック」 forループを最後に使用したときのことを思い出せません（ .mapおよび.reduce ftw）。 そのため、このためのコンパイラオプションは素晴らしいimoになります（デフォルトではオフにすることができます）。 多くのプロジェクトでは、指定したケースのようなものに遭遇することはなく、配列の破棄などにインデックス署名のみを使用します。

（私の元のコメント：https：//github.com/microsoft/TypeScript/issues/13778#issuecomment-517759210）

正直なところ、forループでインデックスを作成することもめったにありません。 私はObject.entriesまたはArray#mapを多用していますが、オブジェクトにインデックスを付けるためにキーを渡す必要があるか、配列またはタプルにインデックスを付ける必要があります。 forループは確かに不自然な例でしたが、どちらのオプション（ undefinedかどうか）にも欠点があるという点があります。

しかし、どちらのオプション（ undefinedかどうか）には欠点があるという点があります。

ええ、TypeScriptのユーザーがどちらの欠点を好むかを選択できればいいのですが：wink：

正直なところ、forループでインデックスを作成することもめったにありません。 私はObject.entriesまたはArray#mapを多用していますが、オブジェクトにインデックスを付けるためにキーを渡す必要があるか、配列またはタプルにインデックスを付ける必要があります。

必要な場合は、 Array#entries使用できます。

for (const [index, foo] of array.entries()) {
    bar(index, foo)
}

私は個人的にArray#forEachをあまり使用せず、反復にArray#mapを使用することはありません（ただし、マッピングには常に使用しています）。 私は自分のコードをフラットに保つことを好み、for ... ofループから抜け出す機能に感謝しています。

タプルが本当に違うかどうかはわかりません。 それらはRESTタイプ（たとえば[str, ...num[]] ）に対応する必要があり、技術的にはaa[Infinity]は完全に有効なJavascriptであるため、それらの特殊なケースを作成するのは複雑になることがわかりました。

あなたの投稿はまた、インデックスリターンを未定義として扱うためのサポートを得た場合にどのようになるかについて考えさせられました。 あなたの例のように、 aa[num]実際にstring | number | undefined場合、インデックスが範囲内にとどまることがわかっていても、 for (let i = 0; i < 2; i++) { foo(aa[i]!); }と書く必要がありますか？ 私にとって、厳密なnullチェックが私が書いたものにフラグを立てるとき、私は最初に物事をよりよく入力するか、ランタイムガードを使用することによってそれを修正できるようにしたいです-null以外のアサーションに頼る必要がある場合、私は通常私の側の失敗としてそれを見てください。 しかし、この場合、私はそれを回避する方法がわかりません、そしてそれは私を悩ませます。

tuple[number]常にT | undefinedと入力されている場合、インデックスが正しくバインドされていることがわかっている場合をどのように処理しますか？

タプルを繰り返し処理するfor(let i..)がそれほど多くあるかどうかはわかりません。
タプルのタイプが1つである場合、ユーザーは配列を使用する可能性があります。

私の経験では、タプルは混合型に最適であり、それが一般的な場合であれば、とにかく型チェックを行っています

var str = '';
var num = 100
var aa = [str, num] as const
for (let i = 0; i < aa.length; i++) {
 aa[i] // needs some type check anyway to determine if 'string' or 'number'
}

また、この提案された変更が発生すると仮定すると、人々がこれを行うのを妨げているのは何ですか？

// this sucks
for (let i = 0; i < 2; i++) { 
   foo(aa[i]!); // ! required
}

// this would work
for (let i = 0 as 0 | 1; i < 2; i++) { 
   foo(aa[i]); //  ! not required 
}

この問題を修正するときに、 0 | 1代わりにkeyof typeof aa使用できます。

i演算を実行する場合、型安全性はありません。
しかし、それは本当に人々がデフォルトの「厳密にはタイプセーフではないが便利な」配列よりもタイプセーフティのためにこれを選択することを可能にします

??と?.演算子があるということは、 Arrayランダムアクセスするのがそれほど面倒では
しかしまた、それはおそらくはるかに一般的です

• 反復（たとえば、 .mapまたは.forEach 、「 T | undefined 」の必要がない場合、コールバックは範囲外のインデックスで実行されることはありません）または
• ループ内でArrayをトラバースします。その一部は、静的に安全であると判断できます（ for...of .. _sparse array_を除いて、 for...inは安全だと思います）。

また、最初に<index> in <array>チェックされた場合、変数は「安全なインデックス」と見なされる可能性があります。

_明確化_： Array<T>にインデックスタイプ[number]: T | undefinedがない（代わりに[number]: T ）という元の理由について話しているのですが、それは使いにくいということでした。
つまり、もはやそうではないので、 undefinedを追加することができます。

@ vp2177問題は機能ではありません（はい、 ?.機能します）。問題は、コンパイラがそれについて警告せず、足で自分自身を撃つことを妨げていることです。

リンティングルールでそれができるかもしれませんが、それでも。

はい、 ?.機能します

失礼ですが同意できません。 ?.は、インデックス付きの値のプロパティにアクセスするために機能しますが、コンパイラは、値が定義されているかどうかに関係なく、値が定義されていると言います（＃35139を参照）。

さらに、eslintを使用してno-unnecessary-conditionを使用する場合、コンパイラは未定義ではないと言って?.不要になるため、このようなアクセスは不要としてフラグが付けられ、削除されます。

@martpie申し訳ありませんが、あなたは私のコメントを誤解したと思います、説明を追加しました。

つまり...人々がこのタイプの行動を選択できるようにする--strictIndexChecksなどを用意するのは良い考えのようです。 そうすれば、それは誰にとっても重大な変化ではなく、より厳密なタイプの環境を提供します。

Flowデフォルトでインデックスに対してこのように機能し、前述の問題はないと思いますが、使用してからしばらく経ち、誤解される可能性があります。

@bradennapier Flowは、 Arrayのインデックス署名でもT | undefined使用しません（残念ながら、TypeScriptと同じです）。

私は以前、みんなを幸せにすることができるアプローチを提案しました。 言い換えれば、それを繰り返しても大丈夫だといいのですが。

基本的に、インデックス署名のデフォルトの動作は次のように変更されます。

• 配列またはオブジェクトから読み取るときに| undefined含める
• 書き込むときに| undefined含めないでください（オブジェクトにはT値のみが必要なため）

定義は次のようになります。

type MaybeUndefined = {[key: string]: string};
const t: MaybeUndefined = {};

const x = t['foo'] // Has type string | undefined
t['foo'] = undefined // ERROR! 
t['foo'] = "test" // Ok

タイプにundefined含めたくない場合は、コンパイラオプションを使用して無効にするか、 !演算子を使用して一部のタイプに対してのみ無効にすることができます。

type AlwaysDefined = {[key: string]!: string};
const t: AlwaysDefined = {};

const x = t['foo'] // Has type string
t['foo'] = undefined // ERROR! 
t['foo'] = "test" // Ok

既存のコードを壊さないために、 undefinedが含まれるようにする新しいコンパイラオプションを導入することもお勧めします（上記のMaybeUndefinedタイプで示されているように）。 そのオプションが指定されていない場合、すべてのインデックス署名タイプは、宣言内で!演算子が使用されたかのように動作します。

思いついた別のアイデア：コード内のいくつかの場所で、2つの異なる動作（ undefinedかどうか）で同じタイプを使用したい場合があります。 新しいタイプマッピングを定義できます。

type MakeDefined<T> = {[K in keyof T]!: T[K]}

それはTypeScriptの良い拡張でしょうか？

私はそのアイデアが好きですが、最初にhttps://github.com/microsoft/TypeScript/issues/2521を取得する必要があると思い誤解しないでください、私はまだ絶対にすべきだと信じていますが、私はm息を止めていない。

@bradennapier Flowは、 Arrayのインデックス署名でもT | undefined使用しません（残念ながら、TypeScriptと同じです）。

うーん、オブジェクトインデックスはどうですか？ 配列の必要性に遭遇したことはありませんが、オブジェクトを使用するときにチェックできることはかなり確かです。

@bradennapierオブジェクトインデックス？ のように、 o[4]ここで、 oはタイプobjectですか？ TypeScriptではそれができません.....

タイプ「4」の式を使用してタイプ「{}」にインデックスを付けることはできません
プロパティ「4」はタイプ「{}」に存在しません。ts（7053）

@RDGthreeは、すべてのことについてMicrosoftの白騎士ではありませんが、最初の返信でmhegazyからこのビットを見逃したようです。

strictNullChecksを除いて、型システムの動作を変更するフラグはありません。 フラグは通常、エラー報告を有効/無効にします。

そして少し後のRyanCavanaughには次のようなものがあります。

私たちは、誰もが実際にこのフラグから利益を得るだろうということにかなり懐疑的です。 地図や地図のようなものはすでにオプトインできます| それらの定義サイトでは未定義であり、配列アクセスでEULAのような動作を強制することは勝利のようには思えません。 これを口に合うようにするには、CFAとタイプガードを大幅に改善する必要があるでしょう。

だから基本的に-彼らは旗が求められているという事実を完全に知っています、そして今のところ彼らは人々がこれから得るだろうと示唆されているかなり疑わしい利益のために彼らのために働く価値があると確信していません。 正直なところ、私は驚かない。なぜなら、誰もがすでに取り上げられたのとほぼ同じ提案や例を持ってここに来続けているからだ。 理想的には、配列にはfor ofまたはメソッドを使用し、オブジェクトの代わりにMap使用する必要があります（または、あまり効果的ではありませんが、 'T | undefined`オブジェクト値）。

私がここにいるのは、人気のあるDTパッケージを維持していて、httpヘッダーマップなどに|undefinedを追加するように求められているためです。これは、既存の使用法のほとんどすべてを壊してしまうことを除けば、完全に合理的です。 、そしてそれがObject.entries()ような他の安全な使用法を使用するのをはるかに悪くするという事実。 あなたの意見がTypescriptの作成者の意見よりも優れていることに不満を言う以外に、ここでのあなたの貢献は実際には何ですか？

サイモン、多分私はあなたのコメントを読み間違えました、しかしそれは元の提案を支持する議論のように聞こえます。 「ラストマイル」の欠落している機能は、コンテキストに応じて、プロパティを| undefinedとして扱うことですが、それ以外の場合は扱いません。 そのため、私は＃2521アップスレッドに例えました。

理想的なシナリオでは、次のように配列またはオブジェクトを宣言できます。

ts const arr: Array<T>; const n: number; const obj: {[k: K]: V}; const k: K;

私はどういうわけかで終わることができます

• arr[n]はT | undefined
• arr[n] = undefinedはエラーです
• T | undefinedではなくTと入力された値を与える、 arrある種の反復にアクセスできます。
• obj[k]はV | undefined
• obj[k] = undefinedはエラーです
• たとえば、 Object.entries()は、 [K, V]タプルを提供するはずであり、未定義のものはありません。

私の見解では、この問題を定義するのは問題の非対称性です。

forループを使用する開発者にとって問題であるという声明は、配列分解を使用する開発者を考慮に入れていないと言えます。 Typescriptで壊れており、この問題のために修正されません。 不正確なタイピングを提供します。 実行されるIMOアレイの破棄は、まだforループを使用しているものよりもはるかに大きな問題です。

const example = (args: string[]) => {
  const [userID, duration, ...reason] = args
  // userID and duration is AUTOMATICALLy inferred to be a string here. 
 // However, if for whatever reason args is an empty array 
// userID is actually `undefined` and NOT a `string`. 

// This is valid but it should not be because userID could be undefined
userID.toUpperCase()
}

問題の元のポイントから離れすぎたくないのですが、関数の引数にタプル型を使用して、そのサンプルメソッドを実際に宣言する必要があります。 関数が([userId, duration, ...reason]: [string, number, ...string[]]) => {}として宣言されている場合は、そもそもこれについて心配する必要はありません。

私はそれをキャストすることができたと確信していますが、それは実際には解決策ではありません。 同様に、ここにいる誰もがforループ配列のインデックスを作成するだけでなく、この問題全体をミュートにすることができます。

for (let i = 0; i < array.length; i++) {
  const value = array[i] as string | undefined
}

問題は、Typescriptがこの動作について警告しないことです。 開発者として、これらを未定義として手動でキャストすることを忘れないでください。これは、ツールが開発者により多くの作業を引き起こすための悪い動作です。 また、公平を期すために、キャストは実際には次のようになっている必要があります。

const example = (args: [string | undefined, string | undefined, ...string[] | ...undefined[]]) => {

}

それは全然良くありません。 しかし、私が上で言ったように、主な問題はそれをこのようにタイプする必要さえありません、そのTSはこれについて全く警告しません。 これは、コードをプッシュすることを忘れている開発者につながります。クールなCIは、tscのマージとデプロイに問題がないことを発見しました。 TSはコードに自信を与え、不正確な入力が提供されると誤った自信を与えます。 =>実行時のエラー！

これは「キャスト」ではなく、正式なパラメータを適切に入力しています。 私のポイントは、あなたが正しくあなたの方法を入力した場合、（古い署名で危険な状態でそれを呼び出した後、誰ということでしたargs: string[] 、彼らが必要としてそれらが保証されていないとき）今、コンパイル時にエラーが発生します適切な数の引数を渡します。 必要なすべての引数を渡さずに、実行時に自分でチェックすることで人々を逃がし続けたい場合は、実際には(args: [string?, number?, ...string[]])と書くのは非常に簡単です。 これはすでにうまく機能しており、この問題にはあまり関係ありません。

これは、問題をその関数からこの関数を呼び出している別の関数に移動するだけです。 ユーザーが提供した文字列を個別の値に解析する必要があるため、配列の破棄を使用してこの関数を呼び出すcommandHandler内で解析すると、同じ問題が発生します。

配列の破棄に不正確な型指定を提供することを回避する方法はありません。

問題の元のポイントから離れすぎたくない

注：個別の問題として扱う必要があることに同意しますが、誰かがアレイの破棄の問題を示す問題を開いているときはいつでも、それは閉じられ、ユーザーはここに転送されます。 ＃38259＃36635＃38287など...だから、この問題のトピックから逸​​脱しているとは思わない。

この問題に対する私の不満のいくつかは、オブジェクトアクセスから推測されるタイプに| undefinedを適用するためのいくつかの単純な構文によって解決されます。 例えば：

const complexObject: { [key: string]: ComplexType } = { ... };
const maybeKey = 'two';

// From:
const maybeValue = complexObject[maybeKey] as
  | (Some<Complex<Type>> & Pick<WithPlentyOf, 'Utility'> & Types)
  | undefined;

// To:
const maybeValue2 = complexObject[maybeKey] as ?;

したがって、より厳密なタイプチェックはオプトインのままです。 以下は機能しますが、複製が必要です（そしてすぐに同じ量の視覚的ノイズが追加されます）：

const maybeValue2 = complexObject[maybeKey] as
  | typeof complexObject[typeof maybeKey]
  | undefined;

この種の「typeasserttomaybe」構文（ as ? ）も、新しいユーザーにとってひどく混乱しないrequire-safe-index-signature-access eslintルールの実装を容易にするだろうと思います。 （例：「最後にas ?を追加することで、lintエラーを修正できます。」）ルールには、コンパイルの中断のみが発生し、実行時の問題は発生しないため、安全な自動修正機能を含めることもできます。

function eh<T>(v: T): T | undefined {
    return v;
}

const arr = [0, 1, 2, 3, 4, 5];
const thing1 = arr[1]; // number
const thing2 = eh(arr[1]); // number | undefined

この驚きのTS機能を除いて、これの単一のアプリケーションはないと思いますが、

function eh<T>(v: T): T | undefined {
    return v;
}

const arr = [0, 1, 2, 3, 4, 5];
const thing1 = arr[1]; // number
const thing2 = eh(arr[1]); // number | undefined

返信ありがとうございます。 このような関数は機能しますが（ほとんどのJSエンジンでほぼ確実に最適化されます）、コンパイルされたJSファイルにこのメソッド「ラッパー」を保持させるよりも、前述の追加の構文ノイズ（ as ComplexType | undefined ）を受け入れたいと思います。 「それが使われるところならどこでも。

別の構文オプション（上記のas ?よりもユースケース固有ではありません）は、型アサーションでinferキーワードを、他の方法で推測される型のプレースホルダーとして使用できるようにすることです。例えば：

const maybeValue = complexObject[maybeKey] as infer | undefined;

現在、 infer宣言は、条件型（ ts(1338) ）のextends句でのみ許可されているため、 inferキーワードにas [...]のコンテキストで意味を与えます。

それでも、eslintルールを介してinfer | undefinedを使用することを強制するの

// Strange example, maybe from an unusual compiler originally written in JS:
if(someRegularExpression.test(maybeKey)) {
  /**
  * If we are inside this code block and this `maybeKey` exists on `partialObject`, 
  * we know its `regexSuccess` must also be defined, though this knowledge 
  * cannot be encoded using TypeScript's type system.
  */
  const maybeValue = partialObject[maybeKey] as (Required<Pick<infer, 'regexSuccess'>> & infer) | undefined;
  // ...
}
// Here we don't know if `regexSuccess` is defined on `maybeValue2`:
const maybevalue2 = partialObject[maybeKey] as infer | undefined;

function eh<T>(v: T): T | undefined {
    return v;
}

const arr = [0, 1, 2, 3, 4, 5];
const thing1 = arr[1]; // number
const thing2 = eh(arr[1]); // number | undefined

とにかく、別のより安全なパターンを使用することを覚えておく必要がある場合は、役に立ちません。 重要なのは、TypeScriptが、非常に良い日であろうと、疲れていようと、コードベースに不慣れであろうと、私たちの背中を持っていることです。

現在の動作では、型式Array<string>[number]は、「配列に数値でインデックスを付けるときに発生する型」として解釈されます。 あなたは書くことが許されています

const t: Array<string>[number] = "hello";

const t: stringを書くための回り道として。

このフラグが存在する場合、どうなりますか？

Array<string>[number]がstring | undefined場合、書き込みの健全性に問題があります。

function write<T extends Array<unknown>>(arr: T, v: T[number]) {
    arr[0] = v;
}
const arr = ["a", "b", "c"];
// Would be OK
write(arr, undefined);

Array<string>[number]がstring場合、読み取りで説明されているのと同じ問題が発生します。

function read<T extends Array<unknown>>(arr: T): T[number] {
    return arr[14];
}
const arr = ["a", "b", "c"];
// Would be OK
const k: string = read(arr);

「インデックス読み取りタイプの」と「インデックス書き込みタイプの」の両方にタイプ構文を追加するのは複雑すぎるようです。 考え？

Array<string>[number]意味を変更すると、このフラグが宣言ファイルの解釈を変更することを意味するため、非常に問題があることを付け加えておきます。 これはかなりの数の人が有効にするようなフラグのように見えるので神経質になりますが、DefinitelyTypedから公開されたものでエラーが発生したり発生しなかったりする可能性があるため、おそらくすべてが構築されていることを確認する必要があります両方向にきれいに。 この動作で追加できるフラグの数は明らかに非常に少ないため（すべてのタイプのパッケージの64の異なる構成をCIテストすることはできません）、 Array<T>[number]をTままにしておく必要があると思います。

あなたの例では@RyanCavanaugh write(arr, undefined)への呼び出し、 write受け入れられますが、割り当てないでしょうarr[0] = v;もはやコンパイル？

上記のwrite関数がライブラリからのものであり、フラグなしでコンパイルされたJSである場合は、それが正しくないことを確認してください。ただし、ライブラリは選択したフラグを使用してコンパイルできるため、これはすでに既存の問題です。 ライブラリが厳密なnullチェックなしでコンパイルされた場合、その中の関数はstring返す可能性がありますが、実際にはstring|undefined返すはずです。 しかし、最近のほとんどのライブラリはnullチェックを実装しているようです。そうでない場合、人々は不平を言います。 同様に、この新しいフラグが存在すると、ライブラリがそれを実装し始め、最終的にほとんどのライブラリでフラグが設定されることを願っています。

また、頭のてっぺんから具体的な例を見つけることはできませんが、アプリをコンパイルするには、確かにskipLibCheckを設定する必要がありました。 これは、新しいTSリポジトリを作成するときはいつでも、ボイラープレートの標準的なtsconfigオプションです。これは、非常に多くの問題が発生したためです。

個人的に（そしておそらく利己的に）、_ my_コードが一般的に安全になるのであれば、エッジケースにヒットしても大丈夫です。 他のエッジケースに遭遇するよりも、インデックスによって配列にアクセスすることでnullポインターに遭遇することが多いと私は信じていますが、そうでない場合は確信できます。

配列の場合[番号]は文字列です| 未定義の場合、書き込みに関する健全性の問題があります。

私の意見では、 Array<string>[number]は常にstring|undefinedます。 現実には、任意の数の配列にインデックスを付けると、配列のアイテムタイプまたは未定義のいずれかが取得されます。 タプルの場合のように配列の長さをエンコードしない限り、ここでこれ以上具体的にすることはできません。 配列インデックスにstring|undefinedを割り当てることができないため、書き込みの例では型チェックは行われません。

「インデックス読み取りタイプの」と「インデックス書き込みタイプの」の両方にタイプ構文を追加するのは複雑すぎるようです。 考え？

これらは2つの異なるものであるため、これはまさにあるべき姿のようです。 配列にインデックスが定義されることはないため、常に未定義になる可能性があります。 Array<string>[number]のタイプはstring|undefinedます。 Array<T>でTが必要なものを指定するために、ユーティリティタイプを使用できます（名前はあまり良くありません）： ArrayItemType<Array<string>> = string 。 これは、 RecordValue<Record<string, number>, string> = stringようなものが必要になる可能性があるRecordタイプでは役に立ちません。

ここには優れた解決策がないことに同意しますが、インデックスの読み取りの健全性を好むと確信しています。

他の多くの言語（Rustのような「安全な」言語を含む）は境界チェックの責任をユーザーに任せているため、配列でのこれの必要性については特に強く感じていません。そのため、私と多くの開発者はすでにそれを行うことに慣れています。 。 また、これらの場合、構文はfoo[i]ような角かっこ表記を_常に_使用するため、非常に明白になる傾向があります。

とはいえ、 foo.barの署名が正しいかどうかを判断するのは非常に難しいため（フィールドbarが明示的に定義されているため）、これを文字列インデックス付きオブジェクトに追加することを強く望んでいます。または、おそらくundefined （インデックス署名の一部であるため）。 このケース（私はかなり高い価値があると思います）が解決された場合、配列のケースは簡単になり、おそらくやりがいがあります。

「インデックス読み取りタイプの」と「インデックス書き込みタイプの」の両方にタイプ構文を追加するのは複雑すぎるようです。 考え？

javascriptのgetterおよびsetter構文は、型定義に拡張できます。 たとえば、次の構文はTypeScriptによって完全に理解されます。

const foo = {
  _bar: "",
  get bar(): string {
    return this._bar;
  },
  set bar(value: string) {
    this._bar = value;
  }
}

ただし、TSは現在、フィールドの「取得」タイプと「設定」タイプを別々に追跡しないため、これらを単一のタイプに「マージ」します。 このアプローチはほとんどの一般的なケースで機能しますが、ゲッターとセッターが同じタイプを共有する必要がある、セッターのみを定義するフィールドにゲッタータイプを誤って割り当てるなど、独自の欠点があります。

TSがすべてのフィールドに対して「get」と「set」を別々に追跡する場合（実際のパフォーマンスコストがかかる可能性があります）、これらの癖を解決し、この問題で説明されている機能を説明するメカニズムも提供します。

type foo = {
  [key: string]: string
}

基本的に次の省略形になります：

type foo = {
  get [key: string](): string | undefined;
  set [key: string](string): string;
}

配列の意味を変えることを追加する必要があります[number]は、このフラグが宣言ファイルの解釈を変更することを意味するため、非常に問題があります。

生成された宣言ファイルが常に完全なgetter + setter構文を使用している場合、これは手書きのものの場合にのみ問題になります。 現在のルールを残りの短縮構文に適用することは、ここでの解決策になる可能性があります。 それは確かに互換性の問題を解決しますが、 .tsファイルと.d.tsファイルを読み取るための精神的なコストも増加します。

余談：

もちろん、これはゲッター/セッターに関する微妙な警告に対処するものではありません。

foo.bar = "hello"

// TS assumes that bar is now a string, which technically isn't guaranteed when
// custom setters and getters are used.
const result: string = foo.bar

これはさらなるエッジケースであり、TSの目標の範囲内であるかどうかを検討する価値があります...しかし、ここでの私の提案はTypeScriptの現在の動作と一致しているため、どちらの方法でも個別に解決できる可能性があります。

コメントの数ページごとにポップして、＃2521へのリンクをもう一度ドロップする必要があるような気がします。

「インデックス読み取りタイプの」と「インデックス書き込みタイプの」の両方にタイプ構文を追加するのは複雑すぎるようです。 考え？

いいえ！ そして少なくとも（リンクをクリックして...）ここにいる116人が私に同意します。 少なくとも、読み取りと書き込みを異なる方法で入力するオプションがあれば、とてもうれしいです。 これは、その機能のもう1つの優れたユースケースです。

少なくとも読み取りと書き込みを異なる方法で入力するオプションがあれば、私は_とても幸せです_。 これは、その機能の_さらに別の_優れたユースケースです。

読み取りタイプと書き込みタイプを参照する方法があるかどうかを質問することが目的だったと思います。たとえば、書き込みタイプを参照するためにArray<string>[number]=ようなものがあるべきでしょうか。

次の2つのことが発生した場合、＃2521とこの問題の両方が解決されれば幸いです。

• まず、＃2521のように、ゲッターとセッターを別々に入力します
• 次に、この問題で説明されているように、 Array<string>[number]の「書き込みタイプ」がstringで、「読み取りタイプ」がstring | undefinedようにフラグを作成します。

私は（誤って？）前者が後者の基礎を築くと思います。https： //github.com/microsoft/TypeScript/issues/13778#issuecomment-630770947を参照して

@RyanCavanaughクイックメタ質問：その長所/短所/コストをより明確に議論および追跡する目的で、上記のかなり具体的な提案を別の問題として持つ方が便利です

@RyanCavanaugh

const t: Array<string>[number] = "hello";

const t: stringを書くための回り道として。

これはタプルの同じ理由だと思いますか？

const t : [string][number] = 'hello' // const t: string

ただし、タプルは境界を認識しており、より具体的な数値タイプに対してundefinedを適切に返します。

const t0: [string][0] = 'hello' // ok
const t1: [string][1] = 'hello' // Type '"hello"' is not assignable to type 'undefined'.

// therefore this is already true!
const t2: [string][0|1] // string | undefined 

なぜnumberすると、動作が異なるのでしょうか。

これを行うためのメカニズムが整っているようです： https ：

これにより、フラグを追加しなくても私のニーズを満たすことができます。

それが誰かを助ける場合のために、ここに安全でない配列アクセスと配列/オブジェクトの破壊にフラグを立てるESLintプラグインがあります。 タプルや（非レコード）オブジェクトのような安全な使用法にはフラグを立てません。

https://github.com/danielnixon/eslint-plugin-total-functions

乾杯ですが、これは純粋にタイプチェックの領域内にあり、一部のプロジェクトにはリンターや適切なルールがないため、言語レベルで追加する必要があることは明らかです。

@RyanCavanaugh

また、この機能が実際にどのように見えるかをテストしましたが、きれいではないことがわかります

好奇心が強いのですが、あまり良くない部分は何ですか？ あなたがこれについてもっと共有することができれば、おそらく私たちはそれを整理することができます。

これはオプションではなく、デフォルトである必要があり

つまり、TypeScriptの型システムがコンパイル時にJavaScript値が実行時に引き受けることができる型を記述する場合、次のようになります。

• Arrayインデックスを作成すると、もちろんJavaScriptでundefinedを返すことができるため（範囲外のインデックスまたはスパース配列）、正しい読み取り署名はT | undefinedます。
• で"原因"のインデックスArrayあることがundefined介しても可能であるdeleteキーワード。

TypeScript4が防ぐように

const a = [1, 2]
delete a[1]

a[1] = undefined防ぐための良いケースもあります。
これは、 Array<T>[number]が実際に読み取りと書き込みで異なるはずであることを示唆しています。

「複雑」かもしれませんが、JavaScriptで実行時の可能性をより正確にモデル化することができます。
TypeScriptが_作られた_ものはどれですか？

| undefinedデフォルトの動作に戻すというアイデアについて議論する意味はありません。コンパイラの更新により、数百万行のレガシーコードを爆発させるだけのバージョンのTypescriptをリリースすることは決してありません。 そのような変更は、私がこれまでに行ったプロジェクトの中で最も破壊的な変更の1つです。

しかし、私は残りの投稿に同意します。

| undefinedデフォルトの動作に戻すというアイデアについて議論する意味はありません。コンパイラの更新により、数百万行のレガシーコードを爆発させるだけのバージョンのTypescriptをリリースすることはありません。 そのような変更は、私がこれまでに行ったプロジェクトの中で最も破壊的な変更の1つです。

しかし、私は残りの投稿に同意します。

構成オプションの場合は違います。

構成オプションの場合は違います。

それは公平ですが、少なくとも、デフォルトでオフになっている長い「リードイン」期間が予想され、レガシーコードがオンになる前に変換するために多くの時間（6か月？1年？それ以上？）が与えられます。 -ディフォルト。 同様に、v4.0でフラグを追加し、v5.0ではデフォルトでオンに設定します。

しかし、それは遠い未来です。なぜなら、前提条件の機能（セッター/ゲッターのさまざまなタイプ）を実行する価値があるという賛同さえないからです。 ですから私は、デフォルトの振る舞いについて長い間議論する意味がないという声明を支持します。

| undefinedデフォルトの動作に戻すというアイデアについて議論する意味はありません。コンパイラの更新により、数百万行のレガシーコードを爆発させるだけのバージョンのTypescriptをリリースすることはありません。 そのような変更は、私がこれまでに行ったプロジェクトの中で最も破壊的な変更の1つです。

しかし、私は残りの投稿に同意します。

あなたのポイント@ thw0rtedに私はここで妥協案を提案しました： https ：

これにより、かなり後に導入された機能で、まだ広く使用されていないこの機能が可能になり、すでに「ほぼ」存在しているように見え、わずかな変更が必要です。

以下のために"strict"の整合性何かArray<T>と考えるべきである"a list of type T that is infinitly long with no gaps"いつでもこれは、あなたはタプルを使用する必要があり望ましくありません。..

はい、これには欠点がありますが、ここでも、この機能が実装されないことと、ここで求めているとおりに実装されることとの間の公正な「妥協」であると感じています。

同意する場合は賛成してください

これにはまったく新しいオプション/構成が必要であることに同意しません。

strictオプションが無効になっている場合はデフォルトの動作ではないと思いますが、strictオプションを有効にするとBE STRICTになり、古いプロジェクトでも適用されます。 strictを有効にすることは、人々が可能な限り最も厳密で正確な入力を選択することです。 厳密なオプションを有効にした場合、自分のコードに自信を持ちたいと思います。それがTSの最も優れた部分です。 しかし、厳密に有効にした場合でも、これらの不正確な入力は単なる頭痛の種です。

このスレッドを読みやすくするために、会話に意味のある追加を行わなかった接線方向のコメントをいくつか非表示にしました。 一般に、次のようなコメントは、前の212のコメントで以前に作成されたものであり、繰り返す必要はないと想定できます。

• TypeScriptは、初めてチェック動作に非現実的に大きな重大な変更を導入する必要があります-いいえ、これまでに行ったことがなく、将来的に行う予定はありません。長期的な設計目標にもっと取り組んでください。前例のない変更を提唱するためにここに来る前にプロジェクトの
• 構成フラグが存在するという事実を誰も考慮していないという考えに基づいた議論-フラグの後ろに物を置くことは、デフォルトでオンにする必要がないことを意味することを認識しています、これは誰にとっても最初のロデオではありません
• ホールドアップは何ですか、ただすでにそれをしてください！ -さて、あなたがそれをそのように言ったので、私は確信しています😕

ここで解決する必要のある非常に現実的な実用的および技術的な課題があり、このスレッドで意味のある作業を行うことができないのは残念です。旗の後ろにあるものは実際の結果がないこと、またはエラーが発生する可能性があることを示唆するために立ち寄る人々でいっぱいです。 ts-ignore 'dはアップグレードの負担ではありません。

@RyanCavanaugh

まとめありがとうございます。

前例のない変更を提唱するためにここに来る前に、プロジェクトの長期的な設計目標にもっと関与してください。

コメントを削除しました。必要に応じて、このコメントも削除できます。 しかし、プロジェクトの最初の目標を理解する方法：

1.エラーである可能性が高い構成を静的に識別します。

（ソース：https：//github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals）

チェックされていないインデックスアクセスはランタイムエラーにつながる可能性があるため、引用されたコメントを理解していません。 JavaScriptでそのようなことを期待している場合、TypeScriptでは危険で間違った自信を得ることになります。 間違ったタイプはanyよりも悪いです。

さて、あなたがそれをそのように言ったので、私は確信しています

もちろん、あなたはコアメンテナの一人であり、あなたとチーム、そしてtsの貢献者に感謝します。 しかし、それはもはやあなただけのものではありません。 賛成票：365と反対票：6を比較してください！ たった6つ！ それは型安全性に対する大きな需要を示しています。

しかし、解決策について話しましょう。 チームが実現する、または考えられる解決策はありますか？

この場合のts-ignore何が問題になっているのか、もう少し詳しく説明していただけますか？ つまり、

4.0.0-breakingなど、パッチを適用したバージョンのtsの自動公開についてどう思いますか？ 競合に関するいくつかの（多くの？）作業を紹介しますが、誰でも変更をテストしてコードベースを準備することができます（この機能要求だけでなく）。 これは、3〜6か月などの限られた期間で行うことができます。 このバージョンを使用するのは私たちが最初です。

もう。 賛成票：365と反対票：6を比較してください！ たった6つ！ それは型安全性に対する大きな需要を示しています。
-@ Bessonov

ハハ。
@RyanCavanaughの投稿全体に同意するわけではありません。
何百万もありますか？ TSユーザーはいますか？！？ 365は、このスレッドでコメントして賛成するのに十分なこの機能を望んでいます...

githubからの通知はありませんが、この問題の未定義のインデックスを試してみるすべての人に、私のコメントの上にあるドラフトPRを見てください。

@RyanCavanaughは、私たちにそれで遊ぶ機会を与えてくれてありがとう。 かなり小さい（〜105 ts（x）ファイル）コードベースに対して実行し、少し遊んでみました。 重要な問題は見つかりませんでした。 から変更された1行：

const refHtml = useRef(useMemo(() => document.getElementsByTagName('html')[0], []))

に：

const refHtml = useRef(useMemo(() => document.getElementsByTagName('html')[0] ?? null, []))

来週は中規模のプロジェクトで試してみます。

@ lonewarrior556 60倍以上で、賛成票で並べ替えると最初のページに表示されます:)

@Bessonov Typescriptコンパイラのコードベースで試してみるべきだと思います

下位互換性を提供するために、オプトイン/オプトアウトするフラグを設定することもできます。

追加するすべてのフラグは、テストとサポートが必要な別の構成マトリックスです。 そのため、TypeScriptはフラグを最小限に抑えたいと考えています。

@MatthiasKunnenこれが小さなエッジケースの機能である場合、これがフラグを追加しない実行可能な理由であることに同意します。 しかし、配列への直接アクセスはコードに頻繁に現れ、型システムの明白な穴であり、修正するための重大な変更でもあるため、フラグが必要だと思います。

フラグは、これに対する間違ったアプローチです。これは、組み合わせ論的な理由もあります。
問題。 このTypeScriptv5と呼ぶべきです...そのようなアプローチ
テスト可能な組み合わせの数を2 ^ NからちょうどNに変えます。

土曜には、15時56分に2020年8月15日、マイケル・Burkman [email protected]
書きました：

@MatthiasKunnenhttps ：//github.com/MatthiasKunnenこれがいくつかだったら
小さなエッジケースの機能なら、それが実行可能な理由ではないことに同意します
このためのフラグを追加します。 しかし、配列への直接アクセスはコードにかなり現れます
頻繁に、そして型システムの明白な穴であり、また
修正するために変更を壊すので、フラグが必要だと思います。

—
このスレッドにサブスクライブしているため、これを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/microsoft/TypeScript/issues/13778#issuecomment-674408067 、
または購読を解除する
https://github.com/notifications/unsubscribe-auth/AAADY5AXEY65S5HDGNGIPZDSA2O3FANCNFSM4C6KEKAA
。

予期しない未定義のエラーが数百人のユーザーのアプリケーションをダウンさせただけで、このタイプチェックが実施されていればビルド時にキャッチされたはずのエラーです。 TypeScriptは、より信頼性の高いソフトウェアを提供するためのすばらしい方法ですが、その優れた有用性は、この1つの省略によって損なわれています。

ここでコメントしたい次の10人は、代わりにドラフトPR＃39560をテストしてみてはどうでしょうか。

これは、ESLintの@typescript-eslint/no-unnecessary-conditionルールを有効にしたい場合、次のすべてのインスタンスについて文句を言うため、非常に面倒です。

if (some_array[i] === undefined) {

（Typescriptがそう言っているので）それは不必要な状態だと思いますが、そうではありません。 コードベース全体に// eslint-disable-next-line @typescript-eslint/no-unnecessary-conditionを追加する必要はありません。

これを適切に修正することが怠惰なJavascriptプログラマーの作業には多すぎる場合は、 undefinedを追加する代替の配列アクセス構文を使用できる可能性があります。

if (some_array[?i] === undefined) {

（ランダムな構文の提案;代替案を歓迎します）

@Timmmmあなたが作ったコメントのすぐ上のコメントを読んでください。 この提案のバージョンを実装するために試すことができるビルドがあります-それがあなたのeslint問題を解決するかどうか、そこで私たちに知らせることができます。

@ the0rted私はそのコメントを読みました。 それは私の提案のバージョンを実装していません。 たぶん、あなたはちょうどそれを再度読んでください。

申し訳ありませんが、「これ」の提案を言ったとき、私はOPの機能、つまりarray_of_T[i]をT | undefinedとして扱うことを意味しました。 特定のインデックス演算子を「おそらく未定義」としてマークする構文について質問しているようですが、ライアンのPRで実装を使用する場合は、すべてのインデックス演算子が「おそらく未定義」であるため、その必要はありません。 。 それはあなたのニーズを満たしませんか？

はい、そうです-着陸した場合、私は間違いなくそれを使用します。 しかし、この議論から、余分なフラグが追加され、動作するように見えるコードがより複雑になるため（単純なforループの例）、多くの人がそれに抵抗しているという印象を受けました。

だから私は別の提案をしたかったのですが、どうやら人々はそれを嫌っています。 ：-/

善意の入力はすべてありがたいです。@ Timmmmを間違えないでください。 反対票は、これがこの時点でこのスレッドですでに十分に踏みにじられていることを伝えているだけだと思います。

私にとって、型の安全性を全面的に向上させるフラグを追加することは、新しいオプトイン構文を導入するよりもはるかに低コストです。

上記では触れませんでしたが、1回限りのオーバーライドの構文はすでに存在します： if ((some_array[i] as MyType | undefined) === undefined) 。 これは、新しい速記として簡潔としてではないのですが、うまくいけば、それはあなたが非常に頻繁に使用する必要があるだろう構文ではありません。

_元々は@osyrisrblxによってhttps://github.com/microsoft/TypeScript/issues/40435#issuecomment-690017567_に投稿されました

これははるかに安全なオプションのように見えますが、常に定義されていると100％確信しているまれな場合に備えて、別の構文を使用してこの動作をオプトアウトすると便利です。

たぶん!:は常に定義されていると主張できますか？

interface X {
    [index: string]!: number; // -> number
}

interface Y {
    [index: string]: number; // -> number | undefined
}

その提案は問題を誤解します。 問題は、TypeScriptがタイプ自体を理解していることではありません。 この問題は、データへのアクセスに起因します。データへのアクセスは、このスレッドの前半で新しい構文がすでに提案されている場所です。

TypeScript 4.1ベータ版でこれを試すことができます。まもなくリリースされます™（または、今すぐ必要な場合は今夜毎晩！🙂）

これが以前に提供された場合は申し訳ありませんが、 {[index: string]?: number} // -> number | undefinedはサポートできますか？ これは、インターフェイスのオプションのプロパティ構文と一致しています。デフォルトで必要であり、「？」で定義されていない可能性があります。

4.1のコンパイラオプションはかっこいいですが、よりきめ細かい制御も良いでしょう。

リポジトリで試してみたい場合（理解するのに少し時間がかかりました）：

1. typescript @ next yarn (add|upgrade) typescript@nextをインストールします
2. フラグを追加します（私にとってはtsconfig.jsonにあります） "noUncheckedIndexedAccess": true

プロジェクトでこのルールを有効にする過程で、次の興味深いエラーが発生しました。

type MyRecord = { a: number; b: string };

declare const myRecord: MyRecord;

declare const key: 'a' | 'b';
const value = myRecord[key]; // string | number ✅

// ❌ Unexpected error
// Type 'MyRecord[Key] | undefined' is not assignable to type 'MyRecord[Key]'
const fn = <Key extends keyof MyRecord>(key: Key): MyRecord[Key] => myRecord[key];

この場合、 keyはkeyof MyRecord制限されているため、 myRecord[key]がタイプMyRecord[Key] | undefined myRecord[key]を返すとは予想していませんkeyof MyRecord 。

更新：提出された問題https://github.com/microsoft/TypeScript/issues/40666

それはおそらくバグ/見落としです！

プロジェクトでこのルールを有効にする過程で、次の興味深いエラーが発生しました。

type MyRecord = { a: number; b: string };

declare const myRecord: MyRecord;

declare const key: 'a' | 'b';
const value = myRecord[key]; // string | number ✅

// ❌ Unexpected error
// Type 'MyRecord[Key] | undefined' is not assignable to type 'MyRecord[Key]'
const fn = <Key extends keyof MyRecord>(key: Key): MyRecord[Key] => myRecord[key];

この場合、 keyはkeyof MyRecord制限されているため、 myRecord[key]がタイプMyRecord[Key] | undefined myRecord[key]を返すとは予想していませんkeyof MyRecord 。

それはバグだと思います。 基本的に、 keyof Typeに文字列/数値リテラルタイプのみが含まれる場合（実際にはstringまたはnumber ）、 Type[Key]ここでKey extends keyof Type undefined含めるべきではないと思います。

＃13195へのクロスリンク。「ここにはプロパティがありません」と「ここにはプロパティがありますがundefined 」の相違点と類似点も確認します。

ここで設計上の制限に関連するいくつかの問題を追跡する

• ＃41612

参考：このフラグのおかげで、コードベースで2つのバグを見つけました。ありがとうございます。
arr.length > 0をチェックするだけでは、 arr[0]を保護するのに十分ではないのは少し面倒ですが、安全性が高いIMOと比較すると、少し不便です（チェックを書き直して、tscを満足させることができます）。

@rubenlg arr.lengthについて同意します。 最初の要素をチェックするために、コードを次のように書き直しました

const firstEl = arr[0];
if (firstEl !== undefined) {
  ...
}

しかし、 if (arr.length > 2)以上を行う場所がいくつかあり、少し厄介です。 ただし、 .lengthのチェックは、変更するだけなので、とにかく完全にタイプセーフだとは思いません。

const a: number[] = [];

a.length = 1;

if (a.length > 0) {
    const b: number = a[0];
    console.log(b);
}

undefinedます。

ただし、 .lengthのチェックは、変更するだけなので、とにかく完全にタイプセーフだとは思いません。

const a: number[] = [];

a.length = 1;

if (a.length > 0) {
    const b: number = a[0];
    console.log(b);
}

undefinedます。

これは本質的にスパース配列であり、この種のことの範囲外です。 タイプチェッカーを回避するために実行できる非標準または卑劣なことが常にあります。

以前の仮定を無効にする方法は常にあり、それが問題です。 考えられるすべての実行パスを分析するには、コストがかかりすぎます。

const a: number[] = [1]
if (a.length > 0) {
    a.pop();
    console.log(a[0])
}