Typescript: 제안: 인덱스 서명에 undefined를 포함하는 옵션

strictNullChecks를 제외하고 유형 시스템 동작을 변경하는 플래그가 없습니다. 플래그는 일반적으로 오류 보고를 활성화/비활성화합니다.
| undefined 모든 인덱서를 정의하는 라이브러리의 사용자 정의 버전을 항상 가질 수 있습니다. 예상대로 작동해야 합니다.

@mhegazy 흥미로운 아이디어입니다. 배열/객체의 형식 서명을 재정의하는 방법에 대한 지침이 있습니까?

이 interface Array<T> 에 lib.d.ts . 다른 인덱싱 서명도 찾기 위해 정규 표현식 \[\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 컬렉션( Map / Set )의 get 메서드에 대한 형식 서명이 Array 때 T | undefined 반환한다는 점은 흥미롭습니다 Map 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를 수정하고 자신의 코드에서 모든 다운스트림 중단을 수정하고 이것이 가치 제안을 가지고 있음을 보여주기 위해 전체 diff가 어떻게 보이는지 보여주고 싶다면 우리는 해당 데이터에 열려 있습니다. 또는 많은 사람들이 접미사 ! 더 사용하고 싶어하지만 아직 그럴 기회가 충분하지 않은 경우 이 플래그가 옵션이 될 것입니다.

우리는 실제로 누군가가 이 플래그로 어떤 이점을 얻을 수 있을지에 대해 매우 회의적입니다. 지도 및 지도와 유사한 사물은 이미 정의 사이트에서 | undefined 에 옵트인할 수 있습니다.

TypeScript의 목표 중 하나는 특정 작업을 수행하기 위해 사용자가 기억하거나 알도록 의존하기보다 "컴파일" 시간에 오류를 포착할 수 있도록 하는 것 아닙니까? 이것은 그 목표에 어긋나는 것 같습니다. 충돌을 피하기 위해 사용자에게 무언가를 요구합니다. 다른 많은 기능에 대해서도 마찬가지입니다. 개발자가 항상 x를 수행하는 경우 필요하지 않습니다. TypeScript의 목표는 (아마도) 작업을 더 쉽게 만들고 이러한 것들을 제거하는 것입니다.

기존 코드에서 strictNullChecks 를 활성화하고 이미 비교를 했기 때문에 이 버그가 발생했습니다. 그래서 오류가 발생했습니다. 내가 완전히 새로운 코드를 작성했다면 아마 여기서 문제를 깨닫지 못했을 것이고(유형 시스템은 항상 값을 얻고 있다고 나에게 말하고 있음) 런타임 오류로 끝났습니다. TS 개발자가 | undefined 모든 지도를 선언해야 한다는 사실을 기억(또는 더 나쁘게는 알고 있음)하는 것은 TypeScript가 사람들이 실제로 원하는 것을 수행하지 못하는 것처럼 느껴집니다.

우리는 실제로 누군가가 이 플래그로 어떤 이점을 얻을 수 있을지에 대해 매우 회의적입니다. 지도 및 지도와 유사한 사물은 이미 옵트인 가능 | 정의 사이트에서 정의되지 않음
TypeScript의 목표 중 하나는 특정 작업을 수행하기 위해 사용자가 기억하거나 알도록 의존하기보다 "컴파일" 시간에 오류를 포착할 수 있도록 하는 것 아닙니까?

실제로 목표는 다음과 같습니다.

1) 오류가 될 가능성이 있는 구성을 정적으로 식별합니다.

여기서 논의되는 것은 오류 가능성(TypeScript 팀의 의견으로는 낮음)과 언어의 일반적인 생산적 유용성입니다. CFA에 대한 초기 변경 사항 중 일부는 이러한 사항을 보다 지능적으로 결정하기 위해 덜 경계 하거나 CFA 분석을 개선하는 것이었습니다.

TypeScript 팀의 질문은 이러한 엄격함의 예를 제공하기 위해 엄격한 정확성을 주장하는 대신 일반적인 사용에서 실제로 보호해야 하는 오류를 식별할 수 있다는 것입니다.

이 댓글 https://github.com/Microsoft/TypeScript/issues/11238#issuecomment -250562397 에서 추론에 좀 더 들어갔습니다.

일부 개체 (위험)에 해당하는 속성을 가지고 모르는 일부 개체 (안전)에 해당하는 속성을 가지고 있습니까 알고있는 그, 그 : 두 세계에서 키의 유형을 생각하십시오.

다음과 같은 올바른 코드를 작성하여 첫 번째 종류의 키인 "안전한" 키를 얻습니다.

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

키에서 두 번째 종류인 "위험한" 종류를 사용자 입력, 디스크의 임의 JSON 파일 또는 존재할 수 있지만 없을 수 있는 일부 키 목록에서 얻습니다.

따라서 위험한 종류의 키와 인덱스가 있는 경우 여기에 | undefined 있는 것이 좋습니다. 그러나 제안은 " 위험한 키를 위험한 것으로 취급"이 아니라 " 모든 키, 심지어 안전한 키라도 위험한 것으로 취급"입니다. 그리고 일단 안전 키를 위험한 것으로 취급하기 시작하면 인생이 정말 엉망이 됩니다. 다음과 같은 코드를 작성합니다.

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

그리고 타이프 라이터가 당신 불평이 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 를 누르는 방법을 매우 빨리 배우고 중요한 항목을 삭제하지 않을 확률이 사전 설정으로 재설정됩니다. -대화 기준선. 파일이 휴지통으로 이동하지 않을 때 파일을 삭제할 때만 대화 상자가 표시된다면 이제 의미 있는 안전을 확보한 것입니다. 그러나 우리는 아무 생각이 없다 (도 우리 수) 개체의 키는 그렇게 보여주는, 안전인지 아닌지 "당신은 당신이 인덱스에 해당 개체를 원하는거야?" 할 때마다 대화 상자가 표시되지 않는 것보다 더 나은 속도로 버그를 찾을 가능성이 없습니다.

오류 가능성이 있는 구성을 정적으로 식별합니다.

아마도 이것은 " 다른 것보다 오류가 발생할 더 높은 구문을 정적으로 식별합니다."라고 수정해야 합니다. : 윙크 :. 본질적으로 " / 를 사용하려고 할 때 * 를 사용했습니다. make * a warning을 사용할 수 있습니까?"와 같은 버그가 발생했을 때를 기억

이해하지만 범위를 벗어난 색인은 실제적이고 일반적인 문제입니다. 사람들이 이것을 할 수 없는 방식으로 배열을 열거하도록 강요하는 것은 나쁜 일이 아닙니다.

! 저도 사실 싫어합니다. 누군가 와서 가정이 무효가 되도록 변경하면 어떻게 될까요? 원점으로 돌아갔습니다(컴파일러가 잡아야 하는 잠재적인 런타임 오류). 유형에 대해 거짓말을 하거나 ! 사용하는 것에 의존하지 않는 안전한 배열을 열거하는 방법이 있어야 합니다(예: array.forEach(i => console.log(i.name) 와 같은 것을 할 수 없습니까?).

이미 코드를 기반으로 유형을 좁혀 이론상으로는 이러한 경우에 | undefined 를 제거하여 두 가지 장점을 모두 제공하는 안전한 유형을 좁힐 수 있는 패턴을 찾을 수 없었습니까? 유효한 요소에 액세스하고 있지 않다는 것을 컴파일러에 쉽게 전달할 수 없다면 보증이 유효하지 않거나 나중에 실수로 쉽게 깨질 수 있다고 주장합니다.

즉, 나는 하나의 프로젝트에서만 TS를 사용하며 궁극적으로 Dart로 마이그레이션되므로 나에게 실질적인 차이를 만들지 않을 것입니다. 소프트웨어의 일반적인 품질이 좋지 않고 편의상 무시되는 것처럼 보이는 오류를 제거하는 데 도움이 될 기회가 있다는 것이 안타깝습니다. 유형 시스템이 견고하게 만들어지고 이러한 구멍이 발생하지 않는 방식으로 일반적인 성가심이 해결될 수 있다고 확신합니다.

어쨌든, 그것은 단지 내 2 센트입니다.. 나는 이것을 끌고 싶지 않습니다. 우리가 어디에서 왔는지 이해하고 당신이 나보다 훨씬 더 나은 결정을 내릴 수 있다고 확신합니다 :-)

몇 가지 고려해야 할 사항이 있다고 생각합니다. 요소 수를 고려하여 일반적으로 사용되는 배열을 반복하기 위한 많은 패턴이 있습니다. 배열의 인덱스에 무작위로 액세스하는 것이 가능한 패턴이지만 실제로는 매우 드문 패턴이며 정적 오류가 아닐 가능성이 높습니다 . 반복하는 현대적인 방법이 있지만 가장 일반적인 방법은 다음과 같습니다.

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

여분의 어레이가 흔하지 않다고 가정한다면(그들은) value 가 | undefined 가 되도록 하는 것은 거의 도움이 되지 않습니다. 야생에서 이것이 위험한(그리고 오류일 가능성이 있는) 일반적인 패턴이 있는 경우 TypeScript가 이를 고려할 것이라고 생각하지만 일반적으로 사용되는 패턴은 정의되지 않은 인덱스 액세스는 분명히 생산성에 영향을 미치는 것으로 지적된 대로 잠재적으로 유용한 상황에 있는 경우 선택할 수 있습니다.

이전에 CFA를 개선하여 값의 상호 의존성을 표현하는 방법이 있다고 생각합니다(예: Array.prototype.length는 인덱스 값과 관련됨). 그래서 index out of bounds와 같은 것들이 정적으로 분석될 수 있습니다. 분명히 그것은 내가 이해하고 싶지 않은 모든 종류의 극단적인 경우와 고려 사항으로 이루어진 중요한 작업입니다(Anders가 이와 같은 일에 식은땀을 흘리며 깨어날 가능성이 높지만).

따라서 트레이드 오프가 됩니다... CFA 개선 없이 코드의 90%를 청어 로 복잡하게 만들어 잠재적으로 10%의 불량 코드 를 잡아냅니다. 그렇지 않으면 안정성에 대한 자체 결과와 다시 문제가 발생할 수 있는 주요 CFA 개선에 투자하여 안전하지 않은 코드를 찾는 것입니다.

TypeScript가 우리를 우리 자신으로부터 구할 수 있는 것은 아주 많습니다.

이 모든 초점은 배열에 있으며 거기에서 문제가 될 가능성이 적다는 데 동의합니다. 그러나 제기된 원래 문제의 대부분은(내 것과 같은) 일반적인 경우가 항상 존재하는 키라고 생각하지 않는 맵에 관한 것이었습니다.

이 모든 초점은 배열에 있으며 거기에서 문제가 될 가능성이 적다는 데 동의합니다. 그러나 제기된 원래 문제의 대부분은(내 것과 같은) 일반적인 경우가 항상 존재하는 키라고 생각하지 않는 맵에 관한 것이었습니다.

이것이 귀하의 유형인 경우 색인 서명에 | undefined 를 추가하십시오. --noImplicitAny 아래에 색인 서명이 없는 유형으로 색인을 생성하는 것은 이미 오류입니다.
ES6 Map 는 이미 get(key: K): V | undefined; 로 get으로 정의되어 있습니다.

나는 | 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 를 넣는 데는 (적어도) 두 가지 다른 문제가 있습니다.

• 이는 분명히 의도하지 않은 이러한 객체에 undefined를 할당 할 수 있음을 의미합니다.
• Object.values (또는 _.values )와 같은 다른 작업은 결과에서 undefined 를 처리해야 합니다.

tslint는 typescript가 잘못된 유형 정보를 반환하기 때문에(= | undefined 부족) 상수 조건에 대한 가양성 경고를 보고합니다.
https://github.com/palantir/tslint/issues/2944

배열 인덱싱에 | undefined 가 없는 경우 정기적으로 건너뛰는 오류 중 하나는 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 for 있습니다. 더 이상.

현재 개발자에게 유형 시스템이 일관성이 없는 것 같습니다. 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 } 의 속성에 액세스하고 싶습니다. 플래그가 작업하기에 너무 성가신 이유에 대한 사례로 제기되었기 때문에 배열 인덱싱에 대해서만 언급했습니다.

원하는 방식으로 정확하게 다시 작성할 수 있다는 것을 알고 계십니까? (약간의 추가 작업이 주어짐)

예, 모든 사람의 타이핑을 다시 작성하거나 컴파일러 플래그를 켤 수 있습니다 😜

계속해서 Captain O를 플레이하세요...: 오늘 lib.d.ts 다시 작성하고 더 많은 사운드 코드베이스의 행복한 소유자가 되거나 다음 N년 동안 플래그를 기다릴 수 있습니다.

@aleksey-bykov lib.d.ts 를 다시 작성하여 어떻게 할 수 있습니까?

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

그런 다음 lib.es2015.core.d.ts 의 Array 정의에서 다음을 바꿉니다.

[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 도 아닙니다.

일반적인 경우에 옳다

일반적인 경우 에 적합하도록 하려면 값의 존재에 대한 정보를 종속 유형 시스템 을 호출 하는 컨테이너 유형 으로 인코딩해야 합니다 . 이는 그 자체로 나쁜 것이 아닙니다. :) 하지만 ... 일부 편집을 저장하기 위해 오늘날까지 수행되는 모든 현재 유형 스크립트 유형 시스템만큼 복잡할 수 있습니다.

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 이동하는 데 큰 차이를 느끼지 못했습니다. 버그도 잡지 못했습니다. 제 문제는 ! 를 유지하는 유틸리티 함수를 통해 어레이로 작업한다는 것입니다

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 | undefined 대신 T 여기? 현재 저는 배열 및 객체에 대한 색인 조회에 대한 유형 안전한 대안으로 내 코드베이스에서 이러한 도우미를 사용합니다.

// 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] 제공 T | undefined 모든 변수에 대한 외부의 선언 for

@ 알렉세이-코프 우리는 무언가를 논의에도 스마트 -이 '에 대한 실제의 형태 가드 메커니즘이 될 수 있다고 arr[index] 테스트 한 index < arr.length .하지만이 경우 도움이되지 것입니다 어디 pop 루프 중간에

_{Aleksey가 배열을 변경한다는 의미는 아닙니다.}

나는 최근에 Elm에서 Typescript로 앱을 이식했고 인덱싱 작업이 잘못 입력된 것은 아마도 가장 엄격한 TS 설정이 활성화된( this 과 같은 항목도 언바운드된) 내가 겪은 가장 큰 버그 소스 중 하나일 것입니다. ).

• 컨테이너에 대한 돌연변이를 추적할 수 없습니다.
• 인덱스 조작을 추적할 수 없습니다.

이것으로 거의 보장할 수 없습니다. 그렇다면 일반적인 사용 사례가 < array.length 내의 모든 요소에 대한 멍청한 반복인 경우 왜 시도하겠습니까?

내가 평소에 말했듯이

• 오류가 있는 경우 for 문의 절 어딘가에서 시작되었을 가능성이 있습니다: 초기화, 증가, 중지 조건 및 따라서 튜링 전체 유형 검사가 필요하기 때문에 확인할 수 있는 항목이 아닙니다.
• for 절 외부에는 일반적으로 오류가 있을 수 없습니다.

인덱스가 어떻게든 선언되는 한(자신있게 말할 수 있는 것이 없음) 루프 본문 내에서 인덱스가 정확하다고 믿는 것이 합리적으로 공정합니다.

그러나 루프 중간에 팝되거나 배열에서 요소를 제거한 함수에 배열을 전달한 경우에는 도움이 되지 않습니다.

이것은 이것에 대한 정말 약한 주장처럼 보입니다. 이러한 사례는 이미 파손되었습니다. 다른 사례를 수정하지 않기 위한 핑계로 사용하는 것은 의미가 없습니다. 여기 있는 누구도 이러한 사례가 올바르게 처리되거나 100% 정확하기를 요구하지 않습니다. 우리는 정말 일반적인 경우에 정확한 유형을 원할 뿐입니다. TypeScript에는 완벽하게 처리되지 않는 경우가 많이 있습니다. 이상한 일을 하고 있다면 유형이 틀릴 수 있습니다. 이 경우 우리는 이상한 일을 하지 않으며 유형이 잘못되었습니다.

코드를 수정하기 위해 의식 추가하기

이것이 "코드 수정을 위한 의식 추가"인 코드 예제를 보고 싶습니다. 내가 이해하는 것처럼 배열에 대한 기본 for 루프는 감지/제한하기 쉽습니다. 잠재적으로 버그가 아닌 불편하게 되는 단순 for 루프가 아닌 실제 코드

버그를 잡지 않으면서

이로 인해 컴파일에 실패한 작업 코드와 유형이 개발자를 오도하기 때문에 런타임에 throw되는 코드의 예가 있습니다. 이를 뒷받침하는 가치가 0이라는 것은 넌센스입니다.

왜 우리는 단순하게 유지하고 구식 for 루프 주위에 _any_ 마법 동작을 추가하지 않을 수 있습니까? 항상 ! 를 사용하여 작업을 수행할 수 있습니다. 코드베이스가 구식 for 루프로 가득 차 있으면 플래그를 사용하지 마십시오. 내가 작업한 모든 최신 코드베이스는 forEach 또는 for of 를 사용하여 배열을 반복하며 이러한 코드베이스는 추가 유형 안전성의 이점을 얻을 수 있습니다.

우리는 이상한 짓을 하지 않고 유형이 잘못되었습니다.

나에게 이 단락은 이 기능이 없는 좋은 이유처럼 읽힙니다. 범위를 벗어난 배열에 액세스하는 것은 이상한 일입니다. 일반적이지 않은 일(OOBing)을 수행하는 경우에만 유형이 "잘못"됩니다. 배열에서 읽는 대부분의 코드는 범위 내에서 그렇게 합니다. 이 인수에 의해 이러한 경우에 undefined 를 포함하는 것은 "잘못"됩니다.

... 컴파일에 실패한 작업 코드

나는 전혀 알지 못합니다. 구체적으로 지적할 수 있습니까?

왜 우리는 그것을 단순하게 유지하고 구식 for 루프 주위에 마술 동작을 전혀 추가하지 않을 수 있습니까? 당신은 항상 사용할 수 있습니다! 일이 작동하도록 합니다.

"모든 배열 액세스 표현식에는 ! 후행이 있어야 함"이라는 TSLint 규칙과 이 규칙의 유용한 차이점은 무엇입니까?

@RyanCavanaugh 내 가정은 TSLint 규칙이 유형을 좁히거나 제어 흐름 유형 분석을 사용할 수 없다는 것입니다(예: if 액세스 래핑, 예외 발생, return ing 또는 continue 설정되지 않은 경우 https://github.com/Microsoft/TypeScript/issues/13778#issuecomment -336265143의 예에서 구현은 어떻게 됩니까? ! 를 적용하려면 본질적으로 이러한 변수의 유형을 undefined 로 추적하는 테이블을 생성해야 합니다. 나에게 이것은 linter가 아니라 type checker가 해야 할 일처럼 들립니다.

@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

이 버그와 관련이 있다고 생각합니다. https://github.com/Microsoft/TypeScript/issues/17960

env var를 변수에 할당하고 다음을 보호하여 이 문제를 해결할 수 있습니다.

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

일부 노드 유형에 | undefined 를 추가하여 코드 완성을 위해 자주 사용되는 속성으로 편의를 위해 이러한 인터페이스를 확장할 수 있습니다. 에아

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

인덱스 서명에 | undefined 가 없으면 TSC는 Property 'foo' of type 'string | undefined' is not assignable to string index type 'string'. 불평합니다.

추가 | undefined 가 있는 유형과 그렇지 않은 유형으로 작업해야 하는 경우 비용이 든다는 것을 알고 있습니다.

우리가 이것을 없앨 수 있다면 정말 좋을 것입니다.

이 문제에 대한 생각을 정리하려고 합니다.

JavaScript에서 객체는 혼합 백입니다. 두 가지 용도 로

• 키를 알 수 없는 사전 일명 지도
• 키가 알려진 레코드

레코드로 사용되는 개체의 경우 인덱스 서명을 사용할 필요가 없습니다. 대신 알려진 키가 인터페이스 유형에 정의됩니다. 유효한 키 조회는 해당 유형을 반환하고 유효하지 않은 키 조회는 인덱스 서명으로 대체됩니다. 정의된 인덱스 서명이 없고(레코드로 사용되는 개체에 대해 없어야 함) noImplicitAny 가 활성화되어 있으면 원하는 대로 오류가 발생합니다.

사전(일명 맵) 및 배열로 사용되는 객체의 경우 인덱스 서명이 사용되며 값 유형에 | undefined 를 포함하도록 선택할 수 있습니다. 예: { [key: index]: string | undefined } . 모든 키 조회는 유효하며(컴파일 시 키를 알 수 없기 때문에) 모든 키는 동일한 유형을 반환합니다(이 예에서는 T | undefined ).

인덱스 서명은 사전 개체 패턴 및 배열에만 사용해야 하므로 TypeScript가 인덱스 서명 값 유형에서 | undefined 를 적용하는 것이 바람직합니다. 키를 알 수 없고 키 조회가 undefined 반환할 가능성이 있는 경우

Array.prototype.find undefined 반환하거나 array[0] undefined 반환하는 것과 같이 이것이 없으면 보이지 않는 버그의 좋은 예가 있습니다. (비구조화는 키 조회를 위한 설탕 구문일 뿐입니다.) getKey 와 같은 함수를 작성하여 반환 유형을 수정하는 것이 가능하지만 코드베이스에서 이러한 함수의 사용을 강제하려면 원칙에 의존해야 합니다.

내가 올바르게 이해하면 문제는 사전 개체 및 배열에 대한 반사에 관한 것이므로 사전 개체 또는 배열의 키를 매핑할 때 키 조회가 유효한 것으로 알려져 있습니다. 즉, undefined 반환하지 않습니다. 이 경우 값 유형에 undefined 가 포함되는 것은 바람직하지 않습니다. 이 문제를 해결하기 위해 제어 흐름 분석을 사용할 수 있습니다.

이것이 미해결 문제입니까, 아니면 제가 오해하고 있습니까?

내가 언급하지 않은 사용 사례와 문제는 무엇입니까?

객체 유형 정의에 undefined를 넣는 데는 (적어도) 두 가지 다른 문제가 있습니다.

• 이것은 분명히 의도하지 않은 이러한 객체에 undefined를 할당할 수 있음을 의미합니다.
• 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 잘 잡았습니다. 논의는 현재 읽기 작업에 중점을 두고 있지만 인덱서 유형 정의는 실제로 두 가지이며 | undefined 를 추가하면 undefined 값을 쓸 수 있습니다.

실험 중인 safelyAccessProperty 함수( 위에서 @OliverJAsh에서

이 기능은 모든 어레이 오브젝트 인스턴스 (인덱서 작업을 제공 모든 유형)에 제공되는 경우, 확장했다 ++ C에서 같은 수 std::vector 갖는다 .at() OOB 액세스 런타임 예외를 발생 어느 및 확인되지 않은 [] 연산자는 최상의 경우 OOB 액세스에서 SEGFAULT와 충돌하고 최악의 경우 메모리를 손상시킵니다.

OOB 액세스 문제는 TypeScript/JavaScript의 유형 정의 수준만으로는 해결할 수 없으며 이 엄격성 기능이 활성화된 경우 잠재적으로 위험한 인덱서 작업을 제한하기 위해 언어 지원이 필요합니다.

인덱서의 이중 특성은 get 및 set 작업을 함수로 사용하여 속성으로 모델링할 수 있지만 이는 기존의 모든 인덱서 유형 정의에 대한 주요 변경 사항입니다.

유망할 것 같은 한 가지 아이디어: 인덱스 서명을 정의할 때 ?: 사용하여 정상적인 사용에서 때때로 값이 누락될 것으로 예상한다는 것을 나타낼 수 있다면 어떨까요? 위에서 언급한 | 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'];

위의 DT PR에 | 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
        }
    }
}

그러나 실제 코드에서는 오래된 루프가 반복을 변경하는 가능성이 훨씬 적습니다.

이 기능에 대한 수요가 있는 것은 분명합니다. TS팀이 해결책을 찾기를 진심으로 바랍니다. 자체 문제가 있기 때문에 인덱서에 | undefined 를 추가하는 것이 아니라(이미 언급됨) 더 "영리한" 방식으로(읽으면 T|undefined 반환, 쓰기에는 T , 좋은 컴파일러 필요) for 루프 등을 확인하는 등 좋은 제안도 이미 언급했습니다.)

컴파일러 방식으로 확인하기 어려운 사소하지 않은 배열을 변경하고 작업할 때 런타임 오류는 문제가 되지 않습니다. 우리는 대부분의 경우에 오류 검사를 원하고 가끔 ! 하는 것이 좋습니다.

즉, 이보다 엄격한 배열 처리가 구현된다면 이제 #24897을 사용하여 상수로 배열 길이를 확인할 때 멋진 유형 축소를 구현할 수 있을 것입니다. 나머지 요소와 튜플링하도록 배열을 좁힐 수 있습니다.

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[]] 수 있습니다.

다른 문제는 컴파일러 인프라가 지금 그러한 큰 튜플을 지원할 수 있는지, 그리고 그렇지 않다면 얼마나 어려운 일인지입니다.

사물

나는 항상 [key: string (or number, symbol)]: V | undefined 의 인덱스 유형을 원하지만 때때로 undefined 경우를 잊어버립니다. 개발자가 컴파일러에게 "나를 믿으십시오. 이것은 실제로 그런 유형입니다"라고 명시적으로 알려야 할 때마다 안전하지 않다는 것을 알고 있습니다.
Map.get 적절하게(엄격하게) 입력하는 것은 거의 의미가 없지만 어떻게든 일반 객체는 자유 패스를 받습니다.
그래도 이건 유저 랜드에서 쉽게 고칠 수 있어서 나쁘지는 않다. 어떤 경우에도 해결책이 없습니다.

배열

아마도 내가 뭔가를 놓치고 있을지 모르지만 "안전하지 않은 방식으로 배열에 거의 액세스하지 않는다"는 주장은 특히 새로운 컴파일러 플래그를 사용하면 양방향으로 갈 수 있는 것 같습니다.

점점 더 많은 사람들이 다음 두 가지 모범 사례를 따르고 있다고 생각하는 경향이 있습니다.

• 기능적 기본 메서드 또는 라이브러리를 사용하여 배열을 반복하거나 변환합니다. 여기에는 브래킷 액세스가 없습니다.
• 제자리에서 배열을 변경하지 마십시오.

이를 염두에 두고 낮은 수준의 브래킷 액세스 논리가 필요한 유일하고 드문 경우는 유형 안전성의 이점을 누릴 수 있습니다.

이것은 아무 생각이 없는 것처럼 보이며 전체 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 인덱스 서명 자체). 실제 인덱스 서명 자체에는 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 }

나는 이 문제나 찬반 양론, 다양한 제안 등에 대해 읽지 않았습니다. (배열/객체 액세스가 엄격한 null 검사로 일관되게 처리되지 않는다는 사실에 반복적으로 놀란 후 Google에서 발견했습니다.) 관련 제안: 특별히 재정의되지 않는 한 배열 유형 추론을 가능한 한 엄격하게 만드는 옵션입니다.

예를 들어:

const balls = [1, 2 ,3];

기본적으로 balls 는 [number, number, number] 로 처리됩니다. 다음과 같이 작성하여 재정의할 수 있습니다.

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

또한 튜플 요소 액세스는 엄격한 null 검사로 일관되게 처리됩니다. 다음 예제에서 n 는 엄격한 null 검사가 활성화된 경우에도 현재 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://github.com/Microsoft/TypeScript/issues/13778#issuecomment -383072468

이것은 내가 경험한 인덱싱된 유형의 문제를 해결합니다. 기본값이면 좋겠지만 현실 세계에서 많은 것을 깨뜨릴 것이라는 점을 이해합니다.

@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 . 어쨌든, 나는 최근에 이것을 만났고 라이브러리에서 문제를 열었습니다.

스크리퍼/타이핑된 스크리프#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 tsconfig.json 에서 strictNullChecks 활성화되어 있는지 확인하십시오( strict 플래그로도 활성화됨)

사용 사례에 알 수 없는 길이의 배열에 대한 임의의 인덱싱이 필요한 경우 undefined를 명시적으로 추가할 가치가 있다고 생각합니다(그 불안전성을 "문서화"하는 경우에만).

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

튜플은 알려진 길이의 작은 배열에서 작동합니다. 어쩌면 우리는 같은 것을 가질 수 string[5] 를위한 속기로 [string, string, string, string, string] ?

옵션으로 이것을 매우 선호합니다. 특히 strictNullChecks 플래그가 활성화된 경우 유형 시스템에서 눈에 띄는 구멍입니다. 일반 객체는 JS에서 항상 맵으로 사용되므로 TypeScript는 해당 사용 사례를 지원해야 합니다.

함수 매개변수의 배열 파괴로 이 문제가 발생했습니다.

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

여기서 나는 a 가 string | undefined 유형이 될 것으로 예상하지만 그렇게 하지 않는 한 string .

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

코드 기반에 단일 for 루프가 없다고 생각하므로 이 동작을 토글하기 위해 tsconfig의 컴파일러 옵션(이름 strictIndexSignatures )에 플래그를 추가하면 됩니다. 우리 프로젝트를 위해.

이것이 내가 이 문제를 해결하는 방법입니다: https://github.com/danielnixon/total-functions/

좋은 해결 방법입니다. TypeScript 팀에서 이 문제가 해결되기를 진심으로 바랍니다.

프로그래머가 작성된 코드에서 가정을 하고 컴파일러가 그것이 저장되었다고 추론할 수 없는 경우 IMHO를 침묵시키지 않는 한 컴파일러 오류가 발생해야 합니다.

이 동작은 새로운 선택적 연결 연산자와 함께 사용하는 경우에도 매우 유용합니다.

Object.entries() 를 사용하는 동안 오늘 지도와 함께 | undefined 를 사용하는 데 문제가 발생했습니다.

{[key: string]: string[]} 의해 상당히 잘 설명된 Index 유형이 있습니다. 가능한 모든 문자열 키가 Index에 표시되는 것은 아니라는 명백한 경고가 있습니다. 그러나 Index에서 조회한 값을 소비하려고 할 때 TS가 catch하지 않는 버그를 작성했습니다. 정의되지 않은 경우를 처리하지 않았습니다.

그래서 권장대로 {[key: string]: string[] | undefined} 로 변경했지만 이제 Object.entries() 사용에 문제가 발생합니다. TypeScript는 이제 (유형 사양에 따라 합리적으로) 인덱스에 정의되지 않은 값이 지정된 키가 있을 수 있다고 가정하므로 Object.entries() 호출 결과에 정의되지 않은 값이 포함될 수 있다고 가정합니다.

그러나 나는 이것이 불가능하다는 것을 알고 있습니다. undefined 결과를 얻어야 하는 유일한 시간은 존재하지 않는 키를 찾는 것이며 Object.entries() 사용할 때 나열되지 않습니다. 따라서 TypeScript를 행복하게 만들려면 존재 이유가 없는 코드를 작성하거나 경고를 무시해야 합니다.

@RyanCavanaugh , 이에 대한 귀하의 원래 답변 이 여전히 TS 팀의 현재 위치라고 가정합니까? 아무도 스레드를 읽지 않고 더 강력한 JS 컬렉션 프리미티브에 대한 몇 년의 경험이 있는지 확인하고, 이후로 엄격함을 높이기 위해 몇 가지 다른 옵션을 도입했기 때문에 둘 다 이에 대한 충돌입니다.

(여전히 나에게 다소 설득력이 없는 예제가 있지만 이 스레드는 이미 모든 주장을 했으며 다른 의견은 아무 것도 변경하지 않을 것입니다)

누군가가 자신의 lib.d.ts를 수정하고 자신의 코드에서 모든 다운스트림 중단을 수정하고 이것이 가치 제안을 가지고 있음을 보여주기 위해 전체 diff가 어떻게 보이는지 보여주고 싶다면 우리는 해당 데이터에 열려 있습니다.

@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 를 포함하므로 성가신 반면 완전히 정의된 하위 집합만 허용해야 합니다. 사용하여 쉽게 고칠 수 ReadonlyArray<articleNames> 대신 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 (댓글) 에서 좀 더 추론에 들어갔습니다.

세상에 있는 두 가지 유형의 키를 생각해 보십시오. 아는 _do_는 일부 개체에 해당 속성이 있고(안전), _모르는 것은 일부 개체에 해당 속성이 있는 것으로 _알려져 있지 않습니다(위험).

다음과 같은 올바른 코드를 작성하여 첫 번째 종류의 키인 "안전한" 키를 얻습니다.

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

키에서 두 번째 종류인 "위험한" 종류를 사용자 입력, 디스크의 임의 JSON 파일 또는 존재할 수 있지만 없을 수 있는 일부 키 목록에서 얻습니다.

따라서 위험한 종류의 키와 인덱스가 있는 경우 여기에 | undefined 있는 것이 좋습니다. 그러나 제안은 "_위험한_ 키를 위험한 것으로 취급"이 아니라 "_모든_ 키, 심지어 안전한 키라도 위험한 것으로 취급"입니다. 그리고 일단 안전 키를 위험한 것으로 취급하기 시작하면 인생이 정말 엉망이 됩니다. 다음과 같은 코드를 작성합니다.

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

TypeScript는 arr[i] 가 undefined 일 수 있다고 불평하고 있습니다. 이제 다음과 같은 코드를 작성하는 습관이 생겼습니다. 어리석게 느껴집니다.

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]);
}

이 함수는 루프를 통한 두 번째 패스에서 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 다른 예를 들어보겠습니다.

```
$ 노드

상수 오류 = []
찾으시는 주소가 없습니다
arr[7] = 7
7
아
[ <7개의 빈 항목>, 7 ]
for (let i = 0; i < arr.length; i++) {
... console.log(arr[i])
... }
찾으시는 주소가 없습니다
찾으시는 주소가 없습니다
찾으시는 주소가 없습니다
찾으시는 주소가 없습니다
찾으시는 주소가 없습니다
찾으시는 주소가 없습니다
찾으시는 주소가 없습니다
7
정의되지 않음```

어떻게 추론에 대해, 여기부터 @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 희소 배열을 사용하는 경우 Typescript는 이미 올바른 작업을 수행하지 않습니다. --strict-index 플래그가 이 문제를 해결합니다. 컴파일:

const arr = []
arr[7] = 7

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

@RyanCavanaugh 사용자가 어레이에 잘못 액세스하기 쉬운 위치를 보여줄 수 있는 매우 일반적인 예가 하나 있습니다.

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

위의 코드는 getBlock 의 일부 사용이 정의되지 않은(예 getBlock('hello') )을 반환하기 때문에 strictNullChecks 아래에서 컴파일러 검사를 정상적으로 통과해서는 안 됩니다. 내 응용 프로그램을 폭발시키지 않고 정의되지 않은 경우를 정상적으로 처리할 수 있도록 컴파일러에서 발생 플래그를 지정합니다.

그리고 이것은 arr.slice(-1)[0] 를 사용하여 배열의 마지막 요소에 액세스하거나 첫 번째 요소 arr[0] 등에 액세스하는 것과 같은 많은 일반적인 관용구에도 적용됩니다.

궁극적으로 저는 TypeScript가 폭발적인 응용 프로그램을 처리하는 것보다 그러한 오류에 대해 저를 귀찮게 하기를 바랍니다.

이 함수는 루프를 통한 두 번째 패스에서 정의되지 않은 것을 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
}

이봐, 나는 그 구문을 알고있다; 저는 이런 루프를 1년에 한 번 작성합니다!

실제로 배열에 대한 인덱스를 수행하는 대부분의 경우 실제로 나중에 undefined 를 확인하고 싶습니다.

이 특별한 경우를 다루기 어렵게 만드는 것에 대한 두려움은 과장된 것 같습니다. 요소를 반복하려는 경우 for .. of 사용할 수 있습니다. 어떤 이유로 요소 인덱스가 필요한 경우 forEach 하거나 entries 반복합니다. 일반적으로 인덱스 기반 for 루프가 실제로 필요한 경우는 극히 드뭅니다.

현상 유지를 원하는 더 나은 이유가 있다면 보고 싶지만 관계 없이: 이것은 시스템의 불일치이며 수정 플래그가 있으면 많은 사람들이 높이 평가할 것 같습니다.

안녕하세요 여러분, 저는 여기서 토론의 많은 부분이
가졌다. 패키지 소유자는 자신의 추론과
이미 이러한 주장의 대부분을 고려했습니다. 그들이 해결할 계획이라면
나는 그들이 그것을 알릴 것이라고 확신합니다. 그 외에는 생각하지 않는다.
스레드는 정말 생산적입니다.

2019년 10월 25일 금요일 오전 11시 59분 brunnerh [email protected]에서 다음과 같이 작성했습니다.

이것은 의식적인 결정입니다. 이 코드가
오류가 되다:

var a = [];for (var i =0; i< a.length; i++) {
a[i]+=1; // a[i]는 정의되지 않았을 수 있습니다.
}

이봐, 나는 그 구문을 알고있다; 저는 이런 루프를 1년에 한 번 작성합니다!

실제로 배열에 대한 인덱스를 수행하는 대부분의 경우에는
실제로 나중에 undefined를 확인하고 싶습니다.

이 특별한 경우를 다루기 어렵게 만드는 것에 대한 두려움은 과장된 것 같습니다.
요소에 대해 반복하려는 경우 .. of에 사용할 수 있습니다. 만약에
어떤 이유로 요소 인덱스가 필요하면 forEach를 사용하거나 반복하십시오.
항목. 일반적으로 정말 필요한 경우는 극히 드뭅니다.
인덱스 기반 for 루프.

현상 유지를 원하는 더 나은 이유가 있다면
보고 싶지만 관계없이 : 이것은 시스템의 불일치입니다.
그리고 그것을 고칠 깃발이 있으면 많은 사람들이 높이 평가할 것 같습니다.

—
당신이 댓글을 달았기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/microsoft/TypeScript/issues/13778?email_source=notifications&email_token=ACAJU3DQ7U6Y3MUUM26J4JDQQM62XA5CNFSM4C6KEKAKY45CNFSM4C6KEKAKYYY3PNVWWK3TUL52HS4DFVEXG43NVMVBW6
또는 구독 취소
https://github.com/notifications/unsubscribe-auth/ACAJU3EWVM3CUFG25UF5PGDQQM62XANCNFSM4C6KEKAA
.

패키지 소유자의 움직임이 없을 수도 있지만 커뮤니티의 지속적인 피드백은 여전히 ​​가치가 있다고 생각합니다. 이 문제에 대한 더 나은 도구에 대한 요구가 여전히 존재하기 때문입니다.

@brunnerh 동의합니다. 요즘은 성능 튜닝을 위한 것이 아니면 for 루프를 사용할 필요조차 없습니다. 이는 대부분의 시간 맵을 변경하기 때문에 회사 코드베이스에서 0%의 시간이 발생하기 때문입니다. /filter/reduce to for 루프는 성능을 거의 향상시키지 않으며 실제 원인은 항상 비효율적인 논리, 네트워크 문제 및 데이터베이스 연결에 있습니다.

아직 아무도 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> 사용하지 않는 이유는 적어도 두 가지입니다.

1. 배열을 사용할 때마다 기억해야 할 또 하나의 사항입니다. 또한 더 이상 암시적 입력을 사용할 수 없습니다.
2. undefined 를 요소 인수로 전달하지 않는 forEach , map 및 filter 의 서명을 변경합니다(해당 인덱스가 명시적으로 그렇게 설정되지 않은 경우). 그 기능을 얼마나 사용하느냐에 따라 처리하기 귀찮을 수 있습니다.

나는 또한 이것이 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_ 런타임 제품 버그의 가능성이 매우 높은 소스입니다.

현재 사용 가능한 선택적 연결 연산자의 인체 공학을 고려할 때 플래그를 통해 이 동작을 사용 가능하게 하지 _하지_ 않기로 한 결정을 다시 검토해야 할 때입니까?

서버에서 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",
    ...
  },
...
}

물론 Windows에서는 작동하지 않지만 없는 것보다는 낫습니다.

이 문제와 인접하여 실행되는 다른 모든 문제는 여기로 리디렉션되는 것 같으므로 여기가 가장 좋은 질문이라고 가정하겠습니다. 테이블에서 선택적 인덱스 서명에 대한 축약 구문입니까? @martpie가 지적했듯이 interface Foo { [k: string]?: Bar; } 보다 인체공학적이지 않은 interface Foo { [k: string]: Bar | undefined; } 을 작성해야 합니다.

?: 교환원 지원을 받을 수 있습니까? 그렇지 않다면 그 이유는 무엇입니까? 즉, 단일 속성 정의를 위한 기능을 추가하기에 인체공학적 이점이 충분했습니다. 인덱스 서명에 "충분히 도움이 되지 않습니까?"

type Foo = { [_ in string]?: Bar } 도 작동합니다. 예쁘지는 않지만 상당히 간결합니다. 원하는 경우 자신만의 Dict 유형을 만들 수도 있습니다. 그러나 ?: 확장에 대해 논쟁하지 않을 것입니다.

이것은 "Javascript: Bad Parts" 이야기 중 하나처럼 느껴지기 시작했습니다.

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 Array의 실제 함수의 경우 올바른 유형을 출력하는 고유한 유형 정의가 있기 때문에 이것이 문제가 될 것이라고 생각하지 않습니다. 예: map : https://github.com/microsoft /TypeScript/blob/master/lib/lib.es5.d.ts#L1331

| undefined 구조가 실제 경험 회귀를 나타내는 유일한 일반적인 코드 사용법은 for ... of 루프입니다. 불행히도 (이 문제의 관점에서) 그것들은 다소 일반적인 구성입니다.

@riggs interface Array<T> { } 가 [index: number]: T | undefined 가 되도록 하는 것에 대해 이야기하고 있다고 생각하지만 @radix 는 현재 권장 사항으로 보이는 것에 대해 이야기하고 있는 것 같습니다. Array<T | undefined> 자신의 코드.

후자는 여러 가지 이유로 좋지 않습니다. 그 중 가장 중요한 것은 다른 패키지의 유형을 제어할 수 없다는 것입니다. 그러나 전자에도 몇 가지 문제가 있습니다. 즉, undefined 를 어레이에 할당할 수 있고 안전한 경우로 알려진 경우에도 undefined 를 제공합니다. 🤷‍♂️

아, 네, 제 오해입니다. 나는 실제로 [index: number]: T | undefined 정의를 사용하는 것에 대해서만 언급했습니다. 유형을 Array<T | undefined> 로 정의하는 것은 해결하는 것보다 더 많은 문제를 일으키는 끔찍한 해결 방법이라는 데 전적으로 동의합니다.

lib.es5.d.ts 를 재정의하는 우아한 방법이 있습니까 아니면 사후 설치 스크립트가 가장 좋은 방법입니까?

@ 신생아 중환자 실-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) 타이프 라이터의 기본 유형 정의의 일부를 오버라이드 (예 : 유형 오버라이드 (override) Object.entries 가 포함 된 배열을 반환하도록 unknown 대신 any ).

이 접근 방식을 사용하여 이 문제를 해결하기 위해 typescript의 배열 유형을 재정의할 수 있는지 확실하지 않지만 시도해 볼 가치가 있습니다.

위의 내용은 선언 병합이 원하는 결과를 제공할 때 작동하지만 단순화하기 위해 인터페이스와 교차하지만 여기서는 덜 제한적인 옵션이 원하는 것입니다.

대신 tsconfig.json 의 files 또는 include 포함된 프로젝트에 사용 중인 모든 lib.*.d.ts 파일을 복사하여 붙여넣은 다음 편집할 수 있습니다. 당신이 원하는 것. /// <reference no-default-lib="true"/> 포함되어 있기 때문에 다른 마법은 필요하지 않지만 /// <reference lib="..."/> 종속성을 제거해야 하는지 확실하지 않습니다. 물론 이것은 모든 명백한 유지 관리상의 이유로 좋지 않습니다.

@butchler 우리도 이 접근 방식을 사용하고 있지만 인덱싱 연산자를 재정의하는 것은 불가능한 것처럼 보였습니다. 다른 Array 함수( filter 유형 가드 포함)를 성공적으로 재정의했지만.

인덱싱 연산자를 재정의하는 이상한 경우가 있습니다.

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

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

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

두 번째 할당은 (당연한 대로) 오류가 발생하지만 첫 번째 할당은 오류가 발생하지 않습니다.
더 이상한 것은 first 위로 마우스를 가져가면 구조화되지 않고 string | undefined 유형이 있지만 할당되는 동안 마우스를 가리키면 string 유형이 있다는 것을 알 수 있습니다

배열 구조화에 대한 다른 유형 정의가 있습니까?

누락된 인덱스와 관련된 오류가 내 코드에서 버그의 빈번한 원인이었기 때문에 이에 대한 솔루션을 찾고 있습니다.

{ [index: string]: string | undefined } 와 같은 유형을 지정하는 것은 해결책이 아닙니다. undefined 값을 포함하지 않는 Object.values(x).forEach(...) 와 같은 반복자에 대한 입력을 엉망으로 만들기 때문입니다.

someObject[someKey] 수행한 후 undefined 를 확인하지 않을 때 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 절충안입니다. 이 문제와 여러 닫힌 문제는 이 변경에 대한 커뮤니티의 높은 요구가 있음을 보여줍니다. ATM 238개 찬성 대 반대 2명. 물론 위의 for 루프가 "올바른" 유형을 추론하지 않는 것은 유감이지만 글쎄요, 대부분의 지지자들은 ! 및 새로운 ? 과 같이 사용할 수 있다고 확신합니다. 주의를 기울이고 안전한 경우에 강제로 사용하십시오. 그러나 다른 쪽에서는 "위험한" 액세스에 대한 올바른 유형을 얻습니다.

큰 코드 기반에 대한 매우 민감한 변경이라는 데 동의하기 때문에 여기에서 제안된 것과 같은 구성 속성에 투표합니다. 적어도 커뮤니티로부터 피드백을 받기 위해서는. 그것이 가능하지 않다면 TS 4.0이 그것을 얻어야 합니다.

이것은 제안된 솔루션이 아니라 실험일 뿐입니다. 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. 이로 인해 코드베이스뿐만 아니라 종속성 중 하나인 io-ts에서도 유형 오류가 발생했습니다. io-ts를 사용하면 자신의 코드에서 사용하는 유형을 생성할 수 있으므로 이 옵션을 자신의 코드베이스에만 적용하고 io-ts의 유형에도 적용하지 않는 것은 불가능하다고 생각합니다. 이는 io-ts 및 아마도 다른 일부 라이브러리가 컴파일러 옵션으로만 도입된 경우에도 이 옵션과 함께 작동하도록 업데이트해야 한다는 것을 의미합니다. 처음에는 이것을 컴파일러 옵션으로 만드는 것이 논란을 덜 수 있다고 생각했지만 옵션을 사용하기로 선택한 사람들이 여러 다른 라이브러리 작성자에게 비호환성에 대해 불평하기 시작하면 단순히 TS 4.0이 되는 것보다 훨씬 더 논쟁의 여지가 있을 수 있습니다. 깨는 변화.

2. 때로는 정의되지 않은 가능성을 제거하기 위해 몇 가지 추가 유형 가드를 추가해야 했습니다. 이것이 반드시 나쁜 것은 아니며 이 제안의 요점이기도 하지만 완전성을 위해 언급한 것입니다.

3. 임의의 Array<T> 반복하는 for (let i = 0; i < array.length; i++) 루프 내부에 유형 오류가 있습니다. T 자체에 undefined 가 포함될 수 있기 때문에 T undefined 를 확인하기 위해 유형 가드를 추가할 수 없었습니다. 내가 생각할 수 있는 유일한 해결책은 A) 유형 어설션 또는 @ts-ignore 를 사용하여 유형 오류를 침묵시키거나 B) 대신 for-of 루프를 사용하는 것입니다. 개인적으로 나는 이것이 너무 나쁘다고 생각하지 않지만(어쨌든 배열을 반복하기 위해 for-of 루프를 사용하는 것이 더 좋지 않은 경우는 거의 없을 것입니다), 논란의 여지가 있습니다.

4. 기존 코드가 이미 .length 값에 대해 일부 주장을 한 다음 배열의 요소에 액세스하는 경우가 많습니다. 이제 .length 검사에도 불구하고 유형 오류가 발생하므로 .length 검사에 의존하지 않도록 코드를 변경하거나 중복 !== undefined 검사를 추가해야 했습니다. 타이프 라이터가 어떻게 든 사용을 허용 할 수 있다면 정말 좋을 것이다 .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) {...} 와 같은 것을 사용할 수 없으므로 ' t 배열 인덱싱에 대해 이 접근 방식을 사용할 것으로 예상합니다. 먼저 배열에서 검사하려는 값을 가져와야 합니다. 내가 말하려는 것은 길이 속성을 확인하고 이를 기반으로 어설션을 만드는 것이 유형 시스템에 너무 많은 스트레스를 줄 수 있다는 것을 이해하기 위해 TS에 의존한다는 것입니다. 전환을 미루게 만든 한 가지는 (당신이 말했듯이 일부 다른 라이브러리에도 오류가 있다는 사실 외에) 배열 구조 분해가 아직 제대로 작동하지 않고 구조 분해 값이 T | undefined 아니지만 T (내 다른 의견 참조).
그 외에는 lib.es5.d.ts 재정의하는 것이 좋은 접근 방식이라고 생각합니다. 미래에 상황이 변경되더라도 변경 사항을 되돌리면 추가 오류가 추가되지 않지만 일부 극단적인 경우는 이미 처리됩니다.
우리는 이미 사용하기 시작했습니다 patch-package 의 변화에 대한 몇 가지 유형 정의 react 하고이 방법은 잘 작동 보인다.

나는 또한 이러한 문제 중 일부를 겪었고, 무언가[i]를 무언가(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 색인 서명을 제안하는 것 같습니다. 그리고 그것들은 완전히 다른 두 개의 토론입니다.

TL;DR 원래 게시물과 제목은 서로 다른 것에 대해 이야기하며, 둘 중 하나를 구현하는 것은 의존적 타이핑에 크게 의존합니다(하).

forEach , map , filter 등과 같은 함수가 존재한다는 점을 감안할 때(IMHO가 훨씬 더 선호됨), TS 팀이 추론 엔진을 일반 for 루프를 사용하여 배열에 대한 루핑을 지원합니다. 나는 그것을 성취하려고 하는 것에서 예상하지 못한 복잡성이 너무 많다는 느낌을 받습니다. 예를 들어 i 는 상수가 아니므로 루프 내에서 누군가 i 값을 변경하면 어떻게 될까요? 물론, 그것은 극단적인 경우이지만 (바라건대) 직관적인 방식으로 처리해야 하는 것입니다.

그러나 인덱스 서명을 수정하는 것은 위의 설명에서 볼 수 있듯이 비교적 간단해야 합니다.

4. 기존 코드가 이미 .length 값에 대해 일부 주장을 하고 배열의 요소에 액세스하는 경우가 많습니다. 이제 .length 검사에도 불구하고 유형 오류가 발생하므로 .length 검사에 의존하지 않도록 코드를 변경하거나 중복 !== undefined 검사를 추가해야 했습니다. 타이프 라이터가 어떻게 든 사용을 허용 할 수 있다면 정말 좋을 것이다 .length 의 필요성 방지하기 위해 확인 !== undefined 확인. 나는 그것을 실제로 구현하는 것이 사소하지 않을 것이라고 가정합니다.

@butchler
궁금해서 이 중 변하는 변수로 접근하는 것과 고정된 숫자로 접근하는 것은 얼마나 될까요? 후자의 경우 TS가 배열 길이를 추적하는 튜플로 배열을 사용하고 있기 때문입니다. 배열을 튜플로 자주 사용하는 경우 실제 튜플로 다시 입력하면 오류가 어떻게 발생하는지 궁금합니다.

배열을 튜플로 자주 사용하는 경우 실제 튜플로 다시 입력하면 오류가 어떻게 발생하는지 궁금합니다.

변수의 유형을 튜플로 변환하기 위해 배열 리터럴에 as const 를 추가하여 유형 오류를 수정한 경우가 있었습니다. 나는 수백 개의 오류 중 약 10개만 보았기 때문에 이것이 우리 코드베이스에서 얼마나 흔한지 전혀 모릅니다.

나는 또한 오늘 이것으로 문제를 쳤다.
계산된 인덱스를 통해 배열에서 액세스하고 있습니다. 해당 인덱스가 범위를 벗어날 수 있습니다.
따라서 코드에 다음과 같은 내용이 있습니다.

const noNext = !items[currentIndex + 1];

그 결과 noNext 가 false 로 정의됩니다. 잘못된 것입니다. 사실일 수 있습니다.
또한 items 를 Array<Item | undefined> 로 정의하고 싶지 않습니다. 잘못된 기대를 제공하기 때문입니다.
인덱스가 있으면 undefined 되어서는 안 됩니다. 그러나 잘못된 색인을 사용하는 경우 undefined 입니다.
물론, 위의 문제는 대신 .length 검사를 사용하거나 noNext 를 boolean 로 명시적으로 정의하여 해결할 수 있습니다.
그러나 결국 이것은 TypeScript를 사용하기 시작한 이후로 저를 괴롭히는 것입니다. 왜 | undefined 가 기본적으로 포함되지 않는지 이해하지 못했습니다.

대부분 typescript-eslint를 사용할 것으로 예상하기 때문에 인덱싱 후 값을 사용하기 전에 확인해야 한다고 강제할 수 있는 규칙이 있습니까? 이는 TS의 지원이 구현되기 전에 도움이 될 수 있습니다.

누군가에게 관심이 있을 수 있는 경우. 이전 댓글에서 lib.es5.d.ts 의 Array 인덱싱 정의를 패치하는 접근 방식이 변경 사항의 영향을 받지 않는 것처럼 보이므로 배열 구조 해제에 대해 이상한 동작이 있다고 언급했습니다. 이에 따라 달라 보인다 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의 모든 사용을 피하려고 시도하므로 이것을 피하려는 추론이 저에게 덜 이해가 됩니다. 그럼에도 불구하고 나는 이것이 배열 구조 분해를 지원하는 데 여전히 중요하다고 생각합니다.

글쎄요, 그것은 단지 모든 배열 구조 분해에 오류가 있으므로 인덱싱을 사용하여 수행해야 합니다.

그래도 나쁘지 않죠? Array Destructuring은 놀라운 기능입니다. 문제는 입력이 정확하지 않다는 것입니다. 기능을 비활성화하는 것은 실제로 좋은 솔루션이 아닙니다. 색인을 사용하는 것은 내 생각에 더 추악한(읽고 이해하기 어려운) 코드와 오류가 발생하기 쉽습니다.

더 보기 흉하지만 개발자가 요소가 정의되었는지 여부를 확인하도록 강제합니다. 더 우아한 해결책을 생각해 냈지만 이것이 가장 단점이 적은 것 같습니다. 적어도 우리의 사용 사례에서는.

@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 는 선택적 연결이 불필요한 것으로 플래그를 지정하고(유형 스크립트에 따라 유형이 null을 허용하지 않기 때문에) 자동 수정이 선택적 연결을 제거하여 인덱스 i 실제로는 정의되어 있지

이 기능이 없으면 내 응용 프로그램, 난 항상 사용하여 액세스 요소에 자신을 상기해야 내가 다차원 배열을 처리하고 있습니다로 매우 버그가되었다 xs[i]?.[j] 대신 xs[i][j] , 또한 내가 명시 적으로 캐스팅해야 유형 안전성을 보장하기 위해 const element = xs[i]?.[j] as Element | undefined 와 같은 액세스 요소.

이것을 만나는 것은 Typescript에서 나의 첫 번째 큰 wtf였습니다. 그렇지 않으면 언어가 놀라울 정도로 신뢰할 수 있다는 것을 알게 되었고 이것이 나를 실망시켰습니다. 그리고 배열 액세스에 "as T | undefined"를 추가하는 것은 상당히 번거롭습니다. 제안 중 하나가 구현되는 것을 보고 싶습니다.

네, 여기도 마찬가지입니다. 그것은 우리가 ( | undefined ) 타입 안전성을 갖는 우리 자신의 타입을 롤아웃하도록 강요했습니다. 대부분 객체 액세스를 위한 것이지만(아마도 별도의 열린 문제일 수 있음) 배열 인덱스에 액세스하는 데에도 동일한 논리가 적용됩니다.

문제를 연결하거나 예제를 보여줄 수 있다는 것이 무슨 말인지 잘 모르십니까?

2020년 4월 29일 수요일 오전 2시 41분 Kirill Groshkov [email protected]
썼다:

네, 여기도 마찬가지입니다. ( |
정의되지 않음) 유형 안전성을 갖습니다. 주로 개체 액세스를 위해(아마도
별도의 미결 문제), 배열 인덱스 액세스에도 동일한 논리가 적용됩니다.

—
당신이 댓글을 달았기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/microsoft/TypeScript/issues/13778#issuecomment-621096030 ,
또는 구독 취소
https://github.com/notifications/unsubscribe-auth/AAAGFJJT37N54I7EH2QLBYDRO7Y4NANCNFSM4C6KEKAA
.

@alangpierce

유망할 것 같은 한 가지 아이디어: 인덱스 서명을 정의할 때 ?: 사용하여 정상적인 사용에서 때때로 값이 누락될 것으로 예상한다는 것을 나타낼 수 있다면 어떨까요? 위에서 언급한 | 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가 이것을 제외하고 정의되지 않은 멤버에 대한 액세스를 방지하기 위해 최선을 다하고 있다는 것은 어리석은 것 같습니다. 이것은 지금까지 우리 코드베이스에서 수정한 가장 일반적인 버그입니다.

[ #38470에서 여기로 토론 이동]
이것이 배열에 실용적이지 않은 이유에 대한 모든 인수를 수락합니다.
나는 이것이 Tuples에 대해 확실히 해결되어야 한다고 생각합니다.

// 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 를 반환했기 때문에 원래 런타임 오류가 발생했습니다.
모두 유형 안전했습니다.

튜플이 실제로 그렇게 다른지 잘 모르겠습니다. 그들은 나머지 유형(예: [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( .map 및 .reduce ftw)에서 "클래식" for 루프를 마지막으로 사용한 시간이 기억나지 않습니다. 이것이 컴파일러 옵션이 훌륭한 imo가 되는 이유입니다(기본적으로 해제될 수 있음). 많은 프로젝트에서 귀하가 제공한 경우와 같은 상황이 발생하지 않으며 배열 구조 해제 등에 인덱스 서명만 사용합니다.

(내 원래 의견: https://github.com/microsoft/TypeScript/issues/13778#issuecomment-517759210)

아, 솔직히 말하면 for-loop를 사용하여 색인을 생성하는 경우도 거의 없습니다. 나는 Object.entries 또는 Array#map 를 광범위하게 사용하지만 가끔은 키를 전달하여 객체에 대한 색인을 생성하거나 (아마도 덜 자주) 배열이나 튜플에 대한 색인을 전달해야 합니다. for 루프는 확실히 인위적인 예였지만, 어느 쪽 옵션( undefined 이든 아니든)에 단점이 있다는 점을 제기합니다.

그러나 이것은 어느 옵션( undefined 이든 아니든)에 단점이 있다는 점을 제기합니다.

예, TypeScript 사용자가 선호하는 단점을 선택할 수 있다면 좋을 것입니다.wink:

아, 솔직히 말하면 for-loop를 사용하여 색인을 생성하는 경우도 거의 없습니다. 나는 Object.entries 또는 Array#map 를 광범위하게 사용하지만 가끔은 키를 전달하여 객체에 대한 색인을 생성하거나 (아마도 덜 자주) 배열이나 튜플에 대한 색인을 전달해야 합니다.

필요한 경우 Array#entries 사용할 수 있습니다.

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

저는 개인적으로 Array#forEach 그렇게 많이 사용하지 않으며, 반복을 위해 Array#map 를 사용하지 않습니다(매핑에는 항상 사용합니다). 나는 내 코드를 평평하게 유지하는 것을 선호하며 for...of 루프에서 벗어날 수 있는 능력에 감사합니다.

튜플이 실제로 그렇게 다른지 잘 모르겠습니다. 그들은 나머지 유형(예: [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..) 이 그렇게 많은지 잘 모르겠습니다.
튜플에 단일 유형이 있는 경우 사용자는 배열을 사용하고,

내 경험상 튜플은 혼합 유형에 적합하며 이것이 일반적인 경우라면 어쨌든 유형 검사를 하고 있습니다.

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 arrays_ 제외, for...in 안전하다고 생각합니다).

또한 변수가 먼저 <index> in <array> 확인되면 "안전한 인덱스"로 간주될 수 있습니다.

_Clarification_ : 나는 원래 이유에 대해 이야기하고 Array<T> 인덱스 유형 가지고 있지 [number]: T | undefined (대신에 단지 [number]: T 가 사용하기에 너무 복잡 될 것이라고했다).
더 이상 그렇지 않으므로 undefined 추가할 수 있습니다.

@vp2177 문제는 기능이 아닙니다(예, ?. 작동). 문제는 컴파일러가 이에 대해 경고하지 않고 발을 쏘는 것을 방지한다는 것입니다.

Linting 규칙이 가능하지만 여전히 그렇습니다.

예, ?. 작동합니다

달라요. ?. 는 인덱싱된 값의 속성에 액세스하는 데 작동하지만 컴파일러는 값이 정의되었는지 여부에 관계없이 값이 정의되었다고 계속 말합니다(#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 유형과 함께 표시됨). 해당 옵션을 지정하지 않으면 모든 인덱스 서명 유형이 선언 내에서 ! 연산자가 사용된 것처럼 작동합니다.

또 다른 아이디어가 떠오릅니다. 코드의 일부 위치에서 두 가지 다른 동작( undefined 여부)으로 동일한 유형을 사용하고 싶을 수 있습니다. 새 유형 매핑을 정의할 수 있습니다.

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

TypeScript의 좋은 확장이 될까요?

아이디어가 마음에 들지만 먼저 https://github.com/microsoft/TypeScript/issues/2521 을 가져와야 한다고 생각합니다. 오해하지 마세요. 여전히 우리가 절대적으로

@bradennapier Flow 는 Array 의 인덱스 서명에서도 T | undefined 를 사용하지 않습니다 (불행히도 TypeScript와 동일).

흠 객체 인덱스는 어떻습니까? 배열에 대한 필요성을 느낀 적은 없지만 개체를 ​​사용할 때 확인하게 만드는 것은 꽤 확실합니다.

@bradennapier 객체 인덱스? o[4] 여기서 o 는 object 유형입니까? TypeScript는 그렇게 할 수 없습니다 .....

'4' 유형의 표현식은 '{}' 유형을 인덱싱하는 데 사용할 수 없습니다.
유형 '{}'.ts(7053)에 속성 '4'가 없습니다.

@RDGthree 는 Microsoft에 대한 모든 것의 화이트

strictNullChecks를 제외하고 유형 시스템 동작을 변경하는 플래그가 없습니다. 플래그는 일반적으로 오류 보고를 활성화/비활성화합니다.

그리고 조금 후에 RyanCavanaugh는 다음과 같이 말했습니다.

우리는 실제로 누군가가 이 플래그로 어떤 이점을 얻을 수 있을지에 대해 매우 회의적입니다. 지도 및 지도와 유사한 사물은 이미 옵트인 가능 | 정의 사이트에서 정의되지 않고 어레이 액세스에 EULA와 같은 동작을 적용하는 것은 승리처럼 보이지 않습니다. 이것을 맛있게 만들기 위해서는 CFA와 타입 가드를 상당히 개선해야 할 것입니다.

기본적으로 그들은 깃발이 요구되고 있다는 사실을 완벽하게 알고 있으며, 지금까지 사람들이 이것으로부터 얻을 수 있는 다소 모호한 이익을 위해 일할 가치가 있다고 확신하지 못했습니다. 솔직히 말해서 나는 놀랍지 않습니다. 왜냐하면 모든 사람들이 이미 언급된 것과 거의 똑같은 제안과 예를 가지고 계속 여기에 오기 때문입니다. 이상적으로는 for of 또는 배열에 메서드를 사용하고 개체 대신 Map 를 사용해야 합니다(또는 덜 효과적으로 'T | undefined' 개체 값).

나는 인기있는 DT 패키지를 유지하고 사람들이 http 헤더 맵과 같은 항목에 |undefined 를 계속 추가하도록 요청하기 때문에 여기에 있습니다. 이는 거의 모든 기존 사용을 중단시키는 비트를 제외하고 완전히 합리적입니다. , 그리고 Object.entries() 와 같은 다른 안전한 사용법을 사용하기 훨씬 더 나쁘게 만든다는 사실. 당신의 의견이 Typescript 제작자의 의견보다 낫다고 불평하는 것 외에 실제로 여기에 기여한 것은 무엇입니까?

Simon, 내가 당신의 의견을 잘못 읽었을 수도 있지만 원래 제안에 찬성하는 주장처럼 들립니다. "라스트 마일" 누락 기능은 컨텍스트에 따라 속성을 | undefined 로 처리 하지만 다른 경우에는 그렇지 않습니다. 그래서 #2521 upthread에 대한 비유를 그렸습니다.

이상적인 시나리오에서는 다음과 같은 배열이나 객체를 선언할 수 있습니다.

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 루프를 사용하는 개발자의 문제라는 말은 Array Destructuring을 사용하는 개발자를 고려하지 못한 것입니다. Typescript에서 깨져 이 문제로 인해 수정되지 않습니다. 부정확한 입력을 제공합니다. 영향을 받는 IMO Array Destructuring은 여전히 ​​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 내부에서 구문 분석하면 동일한 문제가 발생합니다.

Array Destructuring에 부정확한 입력을 제공하는 방법은 없습니다.

문제의 원래 요점에서 너무 벗어나고 싶지 않습니다.

참고: 그것들이 별개의 문제로 다루어져야 한다는 것에 동의하지만, 누군가 어레이 구조 해체 문제를 보여주는 문제를 열면, 그것은 닫히고 사용자는 여기로 전달됩니다. #38259 #36635 #38287 etc... 그래서 나는 우리가 이 문제의 주제에서 벗어나고 있다고 생각하지 않습니다.

이 문제에 대한 불만 중 일부는 | 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;

나는 이런 종류의 "아마도 형식 주장" 구문( 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 엔진에 의해 멀리 최적화 될 것이다) 동안, 나는 오히려 여분의 구문은 잡음 (언급 한 동의 것 as ComplexType | undefined ) 컴파일 JS 파일이 방법을 유지해야 "래퍼 이상 " 어디에나 사용됩니다.

다른 구문 옵션(위의 as ? 보다 사용 사례에 덜 국한됨)은 유형 어설션에서 infer 키워드를 그렇지 않으면 유추된 유형에 대한 자리 표시자로 사용할 수 있도록 허용하는 것입니다. 예:

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

현재 infer 선언에만 허용됩니다 extends 조건 유형 (절 ts(1338) 그래서 제공) 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] 의미를 변경하는 것은 이 플래그가 선언 파일의 해석을 변경함을 의미하므로 실제로 문제가 있음을 추가해야 합니다. 이것은 상당한 수의 사람들이 활성화할 수 있는 일종의 플래그처럼 보이지만 확실히 유형이 지정된 항목에서 오류가 발생하거나 발생하지 않을 수 있기 때문에 신경이 쓰입니다. 양방향으로 깔끔하게 이 동작으로 추가할 수 있는 플래그의 수는 분명히 극도로 작으므로(모든 유형 패키지의 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_ 코드가 일반적으로 더 안전해진다면 극단적인 경우에 타격을 받는 것이 좋습니다. 다른 경우보다 더 자주 인덱스로 배열에 액세스할 때 널 포인터에 부딪힐 것이라고 생각하지만 그렇지 않으면 확신할 수 있습니다.

배열인 경우[숫자]는 문자열입니다 | 정의되지 않은 경우 쓰기에 건전성 문제가 있습니다.

제 생각에는 Array<string>[number] 는 항상 string|undefined 이어야 합니다. 숫자가 있는 배열에 인덱스를 지정하면 배열의 항목 유형 또는 정의되지 않은 항목이 표시되는 것이 현실입니다. 튜플로 할 수 있는 것처럼 배열 길이를 인코딩하지 않는 한 실제로 더 구체적일 수 없습니다. string|undefined 를 배열 인덱스에 할당할 수 없기 때문에 작성 예제는 유형 검사가 아닙니다.

"인덱스 읽기 유형"과 "인덱스 쓰기 유형" 모두에 유형 구문을 추가하는 것은 너무 복잡해 보입니다. 생각?

이것은 두 가지가 다르기 때문에 정확히 무엇이어야 하는 것 같습니다. 배열에는 정의된 인덱스가 없으므로 항상 정의되지 않을 가능성이 있습니다. Array<string>[number] 의 유형은 string|undefined 입니다. 당신이 원하는 것을 지정하려면 T 에서 Array<T> , 유틸리티 유형이 사용될 수를 (잘되지 명명) : ArrayItemType<Array<string>> = string . 이것은 RecordValue<Record<string, number>, string> = string 와 같은 것이 필요할 수 있는 Record 유형에는 도움이 되지 않습니다.

여기에는 훌륭한 솔루션이 없다는 데 동의하지만 인덱스 읽기의 건전함을 선호할 것이라고 확신합니다.

다른 많은 언어(Rust와 같은 "안전한" 언어를 포함하여)는 경계 검사에 대한 책임을 사용자에게 맡기기 때문에 배열에서 이것이 필요하다고 특별히 강하게 느끼지는 않습니다. . 또한 이 구문은 foo[i] 와 같은 대괄호 표기법을 _항상_ 사용하기 때문에 이러한 경우에 매우 명확하게 만드는 경향이 있습니다.

즉, foo.bar 의 서명이 올바른지 여부를 말하기가 매우 어렵기 때문에(명시적으로 정의된 bar 필드로 인해) 문자열 인덱싱된 객체에 이것을 추가하는 것에 대해 강하게 생각합니다. 또는 undefined (색인 서명의 일부이기 때문에). 이 경우(가치가 매우 높다고 생각함)가 해결되면 어레이 사례가 하찮아지고 아마도 할 가치가 있을 것입니다.

"인덱스 읽기 유형"과 "인덱스 쓰기 유형" 모두에 유형 구문을 추가하는 것은 너무 복잡해 보입니다. 생각?

자바스크립트의 getter 및 setter 구문을 유형 정의로 확장할 수 있습니다. 예를 들어 다음 구문은 TypeScript에서 완전히 이해됩니다.

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

그러나 TS는 현재 필드의 "get" 및 "set" 유형을 별도로 추적하지 않기 때문에 단일 유형으로 이들을 "병합"합니다. 이 접근 방식은 가장 일반적인 경우에 작동하지만 getter와 setter가 동일한 유형을 공유해야 하고 setter만 정의하는 필드에 getter 유형을 잘못 할당하는 것과 같은 고유한 단점이 있습니다.

TS가 모든 필드(실제 성능 비용이 있을 수 있음)에 대해 "get" 및 "set"을 별도로 추적하는 경우 이러한 단점을 해결하고 이 문제에 설명된 기능을 설명하기 위한 메커니즘도 제공합니다.

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

본질적으로 다음의 약어가 됩니다.

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

Array의 의미를 변경하는 것을 추가해야합니다.[숫자]는 이 플래그가 선언 파일의 해석을 변경함을 의미하므로 정말 문제가 됩니다.

생성된 선언 파일이 항상 완전한 getter+setter 구문을 사용했다면, 이것은 _only_ 손으로 쓴 것의 문제가 될 것입니다. 현재 규칙을 정의 파일에만 있는 나머지 약식 구문에 적용하는 것이 여기에서 해결책이 될 수 있습니다. 확실히 호환성 문제를 해결할 수 있지만 .ts 파일과 .d.ts 파일을 읽는 정신적 비용도 추가됩니다.

곁에:

물론 이것은 getter/setter의 _모든_ 미묘한 경고를 다루지 않습니다.

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명의 다른 사람들이 나와 동의합니다. 적어도 읽기와 쓰기를 다르게 입력할 수 있는 옵션이 있으면 정말 기쁠 것입니다. 이것은 해당 기능의 또 다른 훌륭한 사용 사례입니다.

적어도 읽기와 쓰기를 다르게 입력할 수 있는 옵션이 있으면 _너무 기쁩니다_. 이것은 그 기능에 대한 _또 다른_ 훌륭한 사용 사례입니다.

나는 의도가 읽기 및 쓰기 유형을 참조하는 방법이 있어야 하는지 질문하는 것이라고 생각합니다. 예를 들어 쓰기 유형을 참조하기 위해 Array<string>[number]= 와 같은 것이 있어야 합니까?

두 가지 일이 발생하면 #2521과 이 문제의 해결에 만족할 것입니다.

• 먼저 #2521에 따라 getter와 setter를 다르게 입력합니다.
• 그런 다음, 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://github.com/microsoft/TypeScript/issues/38779

이것은 추가 플래그를 추가하지 않고도 내 요구를 충족시킬 것입니다.

누군가에게 도움이 될 수 있도록 안전하지 않은 배열 액세스 및 배열/객체 구조화에 플래그를 지정하는 ESLint 플러그인이 있습니다. 튜플 및 (비 레코드) 개체와 같은 안전한 사용에 플래그를 지정하지 않습니다.

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

건배, 하지만 순전히 형식 검사의 영역에 속하고 일부 프로젝트에는 린터나 올바른 규칙이 없기 때문에 이것이 여전히 언어 수준에서 추가되어야 한다는 것이 분명하기를 바랍니다.

@RyanCavanaugh

우리는 또한 이 기능이 실제로 어떻게 보이는지 테스트했으며 아름답지 않다고 말할 수 있습니다.

그냥 궁금해서요. 예쁘지 않은 부분이 무엇인지 알려주실 수 있나요? 이에 대해 더 많은 정보를 공유해 주시면 문제를 해결할 수 있습니다.

이것은 옵션이 아니라 기본값 이어야 합니다.

즉, TypeScript의 유형 시스템이 컴파일 시간에 JavaScript 값이 런타임에 취할 수 있는 유형을 설명하는 경우:

• Array 인덱싱은 물론 JavaScript에서 undefined 를 반환할 수 있으므로(범위를 벗어난 인덱스 또는 희소 배열) 올바른 읽기 서명은 T | undefined 입니다.
• 의 "원인"인덱스 Array 될 undefined 비아도 가능하다 delete 키워드.

TypeScript 4가 방지하므로

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

a[1] = undefined 도 방지하는 좋은 경우가 있습니다.
이것은 Array<T>[number] 가 읽기와 쓰기에 대해 실제로 달라야 함을 시사합니다.

"복잡"할 수 있지만 JavaScript에서 런타임 가능성을 보다 정확하게 모델링할 수 있습니다.
TypeScript는 무엇을 위해 만들어졌습니까?

| undefined 가 기본 동작을 반환하도록 하는 아이디어를 논의하는 것은 의미가 없습니다. 컴파일러 업데이트로 인해 수백만 줄의 레거시 코드를 폭발시키는 Typescript 버전을 출시 하지 않을 것입니다. 그런 변화는 내가 따랐던 어떤 프로젝트에서도 가장 획기적인 변화가 될 것입니다.

그래도 나머지 글에는 동의합니다.

| undefined 가 기본 동작을 반환하도록 하는 아이디어에 대해 논의하는 것은 의미가 없습니다. 컴파일러 업데이트로 인해 수백만 줄의 레거시 코드를 폭발시키는 Typescript 버전을 _절대_ 출시하지 않을 것입니다. 그런 변화는 내가 따랐던 어떤 프로젝트에서도 가장 획기적인 변화가 될 것입니다.

그래도 나머지 글에는 동의합니다.

구성 옵션인 경우에는 그렇지 않습니다.

구성 옵션인 경우에는 그렇지 않습니다.

그것은 공평하지만 최소한 기본적으로 꺼져 있는 긴 "리드 인" 기간을 예상하여 사람들에게 레거시 코드가 활성화되기 전에 변환하는 데 많은 시간(6개월? 1년? 그 이상?)을 줄 것입니다. -기본. 예를 들어 v4.0에 플래그를 추가하고 v5.0에서 기본적으로 on으로 설정하는 것과 같습니다.

그러나 그것은 먼 미래입니다. 왜냐하면 우리는 전제 조건 기능(setter/getter에 대해 다른 유형)이 할 가치가 있다는 동의조차 하지 않았기 때문입니다. 그래서 저는 기본 동작에 대해 오랫동안 논의하는 것은 의미가 없다는 진술을 지지합니다.

| undefined 가 기본 동작을 반환하도록 하는 아이디어에 대해 논의하는 것은 의미가 없습니다. 컴파일러 업데이트로 인해 수백만 줄의 레거시 코드를 폭발시키는 Typescript 버전을 _절대_ 출시하지 않을 것입니다. 그런 변화는 내가 따랐던 어떤 프로젝트에서도 가장 획기적인 변화가 될 것입니다.

그래도 나머지 글에는 동의합니다.

@thw0rted 요점까지 여기에서 타협을 제안했습니다. https://github.com/microsoft/TypeScript/issues/38779

훨씬 나중에 도입된 기능에서 여전히 널리 사용되지 않는 이 기능을 허용하고 이미 "거의" 있는 것처럼 보이며 약간의 변경만 필요합니다.

"strict" 일관성을 위해 Array<T> 는 "a list of type T that is infinitly long with no gaps" 로 간주되어야 합니다. 이것이 원하지 않을 때마다 튜플을 사용해야 합니다.

네, 여기에는 단점이 있습니다. 하지만 다시 한 번 저는 이 기능이 여기에서 요청한 대로 정확히 구현 및 구현되지 않는 것이 공정한 "타협"이라고 생각합니다.

동의하시면 투표해주세요

나는 이것이 완전히 새로운 옵션/구성이 필요하다는 데 동의하지 않습니다.

엄격한 옵션이 비활성화되어 있을 때 기본 동작이 되어야 한다고 생각하지 않지만 엄격한 옵션인 BE STRICT를 활성화하고 이전 프로젝트에서도 이를 적용하면 기본 동작이 되어야 한다고 생각하지 않습니다. 엄격함을 활성화하는 것은 사람들이 가능한 가장 엄격하고 정확한 타이핑을 선택하는 것입니다. 엄격한 옵션을 활성화하면 내 코드에 확신을 갖고 싶습니다. 이것이 TS의 가장 좋은 부분입니다. 그러나 엄격하게 활성화된 경우에도 이러한 부정확한 입력은 골치 아픈 일입니다.

이 스레드를 읽을 수 있도록 유지하기 위해 대화에 의미 있게 추가되지 않은 여러 접선 댓글을 숨겼습니다. 일반적으로 다음 맥락의 주석은 이전 212개의 주석에서 이전에 작성되었으며 반복할 필요가 없다고 가정할 수 있습니다.

• TypeScript는 처음으로 동작 확인에 비현실적으로 큰 변경 사항을 도입해야 합니다. 아니요, 우리는 전에도 그렇게 하지 않았으며 앞으로도 그렇게 할 생각이 없습니다. 장기적인 디자인 목표에 더 많이 참여하십시오. 전례 없는 변화를 옹호하기 위해 여기에 오기 전에 프로젝트의
• 아무도 구성 플래그가 존재한다는 사실을 고려하지 않았다는 아이디어에 입각한 주장 - 플래그 뒤에 물건을 두는 것은 기본적으로 켜져 있을 필요가 없다는 것을 알고 있습니다. 이것은 누구의 첫 번째 로데오가 아닙니다.
• 무슨 일이야, 그냥 해! - 글쎄, 당신이 그것을 그렇게 표현한 지금 나는 확신합니다 😕

여기에서 해결해야 할 매우 실제적이고 기술적인 문제가 있으며 이 스레드에서 의미 있는 작업을 수행할 수 없다는 것은 실망스럽습니다. 플래그 뒤에 있는 모든 것이 실제 결과가 없거나 be ts-ignore 'd는 업그레이드 부담이 아닙니다.

@RyanCavanaugh

요약해주셔서 감사합니다.

전례 없는 변화를 옹호하기 위해 여기에 오기 전에 프로젝트의 장기 설계 목표에 더 많이 참여하십시오.

나는 내 댓글을 지웠고 원하시면 이 댓글도 삭제할 수 있습니다. 그러나 프로젝트의 첫 번째 목표를 이해하는 방법:

1. 오류 가능성이 있는 구성을 정적으로 식별합니다.

(출처: https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals )

확인되지 않은 인덱스 액세스로 인해 런타임 오류가 발생할 수 있으므로 인용된 의견을 이해할 수 없습니다. JavaScript에서 그런 것을 기대한다면 TypeScript에서는 위험하고 잘못된 확신을 갖게 됩니다. 잘못된 유형은 any 보다 나쁩니다.

글쎄, 이제 당신이 그렇게 말했으므로 나는 확신합니다.

물론 당신은 핵심 메인테이너 중 하나이며 ts에 대한 팀과 기여자에게 감사드립니다. 하지만 더 이상 당신만의 문제가 아닙니다. 찬성: 365와 반대: 6을 비교하세요! 단 6! 유형 안전성에 대한 엄청난 요구를 보여줍니다.

그러나 해결책에 대해 이야기합시다. 팀이 만들거나 생각할 수 있는 솔루션이 있습니까?

이 경우 ts-ignore 문제점에 대해 좀 더 자세히 설명해 주시겠습니까? codemod 와 같은 도구를 사용하여 자동화할 수 있으며 현재 코드의 동작을 변경하지 않습니다. 물론 아름다운 해결 방법은 아니지만 플래그 없이 이 변경 사항을 도입할 수 있는 방법 중 하나입니다.

예를 들어 4.0.0-breaking 와 같이 패치된 ts 버전의 자동 게시에 대해 어떻게 생각하십니까? 충돌에 대한 몇 가지(많은?) 작업을 소개하지만 모든 사람이 변경 사항을 테스트하고 코드 기반을 준비할 수 있습니다(이 기능 요청뿐만 아니라). 이것은 3-6개월과 같은 제한된 기간 동안 수행될 수 있습니다. 우리는 이 버전을 사용할 첫 번째 사람이 될 것입니다.

더 이상. 찬성: 365와 반대: 6을 비교하세요! 단 6! 유형 안전성에 대한 엄청난 요구를 보여줍니다.
- @베소노프

ㅋ.
@RyanCavanaugh 의 전체 게시물에 동의하는
수백만이 있습니까? 거기에 TS유저들?!? 365는 이 스레드에 댓글을 달고 찬성할 수 있을 만큼 이 기능을 원합니다...

github의 알림은 없지만 이 문제의 정의되지 않은 인덱스를 사용하려고 하는 모든 사람은 내 의견 위에 있는 PR 초안을 살펴보세요.

@RyanCavanaugh 우리에게 게임을 할 수 있는 기회를 주셔서 대단히 감사합니다. 나는 꽤 작은(~105 ts(x) 파일) 코드 베이스에 대해 그것을 실행하고 조금 가지고 놀았습니다. 중요한 문제를 찾지 못했습니다. 다음에서 변경된 한 줄:

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

에게:

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

나는 다음 주에 중간 프로젝트에서 그것을 시도할 것입니다.

@lonewarrior556 60배 더 많고 upvotes로 정렬하면 첫 페이지에 있습니다 :)

@Bessonov Typescript 컴파일러 코드베이스에서 시도해야한다고 생각합니다. for-loop의 사소한 사용으로 인해 대규모 손상이 발생할 수 있습니다.

이전 버전과의 호환성을 제공하기 위해 옵트인/아웃하는 플래그를 가질 수도 있습니다.

추가하는 모든 플래그는 테스트 및 지원이 필요한 또 다른 구성 매트릭스입니다. 이러한 이유로 TypeScript는 플래그를 최소로 유지하려고 합니다.

@MatthiasKunnen 이것이 작은 경우의 기능이라면 플래그를 추가하지 않는 실행 가능한 이유라는 데 동의합니다. 그러나 직접 배열 액세스는 코드에 매우 자주 나타나며 유형 시스템의 눈에 띄는 구멍이자 수정해야 할 주요 변경 사항이므로 플래그가 필요하다고 생각합니다.

플래그는 이것에 대한 잘못된 접근입니다. 부분적으로는 조합
문제. 우리는 이것을 TypeScript v5... 그런 종류의 접근 방식이라고 불러야 합니다.
테스트 가능한 조합의 수를 2^N에서 N으로 바꿉니다...

2020년 8월 15일 토요일 15:56, Michael Burkman [email protected]
썼다:

@MatthiasKunnen https://github.com/MatthiasKunnen 이것이 일부라면
작은 엣지 케이스 기능을 사용하면
이를 위해 플래그를 추가하십시오. 그러나 직접 배열 액세스는 코드에 꽤 나타납니다.
자주 발생하며 유형 시스템의 눈부신 구멍이자 동시에
수정을 위한 주요 변경 사항이므로 플래그가 정당하다고 생각합니다.

—
이 스레드에 가입했기 때문에 이 메시지를 받고 있습니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/microsoft/TypeScript/issues/13778#issuecomment-674408067 ,
또는 구독 취소
https://github.com/notifications/unsubscribe-auth/AAADY5AXEY65S5HDGNGIPZDSA2O3FANCNFSM4C6KEKAA
.

방금 예상치 못한 정의되지 않은 오류가 수백 명의 사용자에 대한 내 애플리케이션을 중단시켰습니다. 이 유형 검사가 있었다면 빌드 시 오류가 발생했을 것입니다. TypeScript는 우리에게 더 안정적인 소프트웨어를 제공하는 놀라운 방법이었지만 이 한 번의 누락으로 인해 그 뛰어난 유틸리티가 훼손되고 있습니다.

여기에 댓글을 달고자 하는 다음 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 문제가 해결되면 거기에서 알려주십시오.

@0rted 그 댓글을 읽었습니다. 내 제안의 버전을 구현하지 않습니다. 어쩌면 당신은 다시 읽어야한다.

죄송합니다. "이" 제안이라고 했을 때 OP의 기능, 즉 array_of_T[i] 을 T | undefined 로 취급하는 것을 의미했습니다. 특정 인덱스 연산자를 "정의되지 않았을 수 있음"으로 표시하는 구문에 대해 묻는 것을 알지만 Ryan의 PR에서 구현을 사용하는 경우 모든 인덱스 연산자가 "정의되지 않을 수 있음"이므로 필요하지 않습니다. . 그것이 당신의 필요를 충족시키지 않습니까?

예, - 만약/언제 그것이 착륙한다면 나는 확실히 그것을 사용할 것입니다. 그러나 이 토론에서 많은 사람들이 추가 플래그를 추가하고 더 복잡하게 작동해야 하는 것처럼 보이는 코드를 만들기 때문에(단순한 for 루프 예제) 그것에 저항했다는 인상을 받았습니다.

그래서 대안을 제시하고 싶었지만 사람들이 싫어하는 것 같다. :-/

모든 좋은 의도의 입력에 감사드립니다. @Timmmm을 잘못된 방식으로 받아들이지 마십시오. 나는 downvotes가 이것이이 시점에서이 스레드에서 이미 잘 밟힌 기반이라는 것을 전달할 뿐이라고 생각합니다.

저에게는 전반적으로 유형 안전성을 향상시키는 플래그를 추가하는 것이 새로운 옵트인 구문을 도입하는 것보다 비용이 훨씬 저렴합니다.

위에서 언급하지 않았지만 일회성 재정의 구문이 이미 존재합니다: if ((some_array[i] as MyType | undefined) === undefined) . 그것은 새로운 속기로 간결로 아니지만 잘하면 당신이 자주 사용해야 할 거라고 구조 아니에요.

_Originally에 @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 유형을 반환할 것이라고 기대하지 않았습니다.

업데이트 : 제출된 문제 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 유형을 반환할 것이라고 기대하지 않았습니다.

나는 그것이 버그라고 말하고 싶다. 기본적으로 keyof Type 문자열/숫자 리터럴 유형만 포함되는 경우(실제로 string 또는 number 포함하는 것과 반대) Type[Key] 여기서 Key extends keyof Type undefined 포함해서는 안 된다고 생각합니다.

#13195에 대한 교차 연결, "여기에 속성이 없습니다"와 "여기에 속성이 있지만 undefined " 간의 차이점과 유사점도 살펴봅니다.

여기에서 설계 제한과 관련된 몇 가지 문제 추적

• #41612

참고: 이 플래그 덕분에 내 코드베이스에서 두 개의 버그를 잡았습니다. 정말 감사합니다!
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])
}