Typescript: 제안: nullable이 아닌 유형

본질적으로 nullable이기 때문에 string 이외의 유형을 예로 사용하는 것이 좋습니다. :피
"!"의 사용자와 컴파일러 때문에 nullable이 아닌 유형이 문제가 있음을 인식할 수 있습니다. 유형이 항상 null이 아닌 것으로 예상하며 이는 JavaScript에서 진정으로 주장될 수 없습니다. 사용자는 다음과 같이 정의할 수 있습니다.

function(myNonNull:!myClass):void {
  myNonNull.foo();
}

그리고 null이 아닌 것으로 정의되어 있기 때문에 컴파일러에게는 모든 것이 만족스러울 수 있지만 자바스크립트에서 이를 사용하는 다른 누군가는 null과 kaboom을 전달합니다.

이제 해결 방법은 공개 방식의 경우 not null을 자동으로 어설션하는 것일 수 있습니다. 그러나 컴파일러는 강제할 수 없기 때문에 !nonnull 선언을 가질 수 있는 public 속성(또는 실제로는 private)을 가질 수 없다고 주장할 수도 있습니다.

이것은 적절하게 시행되기 위한 코드 계약에 대한 논의로 더 깊이 들어갈 수 있습니다.

비평가를 용서하십시오. 대수 데이터 유형이 여기에 있는 경우 null을 허용하지 않는 유형이 거의 필요하지 않다고 생각합니다. 사람들이 누락된 값을 나타내기 위해 null 를 사용하는 이유는 JavaScript와 대부분의 OOP 언어에서 더 나은 방법이 없기 때문입니다. 따라서 이미징 ADT는 이미 여기에 있습니다. 그런 다음, nullable이 아닌 이전에 작성된 오래된 libs에 관해서는 그것들을 가지고 있다고 해서 삶이 더 나아지지는 않을 것입니다. 새로운 라이브러리의 경우 ADT를 사용하면 null을 전혀 사용하지 않고도 비즈니스 도메인 사양에 따라 취할 수 있는 값을 매우 정확하게 모델링할 수 있습니다. 그래서 내가 말하는 것은 ADT가 같은 문제를 해결하는 훨씬 더 강력한 도구라는 것입니다.

개인적으로, 나는 약간의 Maybe<T> 인터페이스를 작성했고 해당 유형의 변수가 null이 되지 않도록 규율을 사용했습니다.

본질적으로 nullable이기 때문에 string 이외의 유형을 예로 사용하는 것이 좋습니다. :피
"!"의 사용자와 컴파일러 때문에 nullable이 아닌 유형이 문제가 있음을 인식할 수 있습니다. 유형이 항상 null이 아닌 것으로 예상하며 이는 JavaScript에서 진정으로 주장될 수 없습니다. 사용자는 다음과 같이 정의할 수 있습니다.

함수(myNonNull:!myClass): 무효 {
myNonNull.foo();
}
그리고 null이 아닌 것으로 정의되어 있기 때문에 컴파일러에게는 모든 것이 만족스러울 수 있지만 자바스크립트에서 이를 사용하는 다른 누군가는 null과 kaboom을 전달합니다.

나는 당신이 다음을 정의 할 수도 있다는 것을 정말로 이해하지 못합니다.

function myFunc(str: string): int {
 return str && str.length;
}

누군가가 int 를 해당 함수에 전달하면 오류도 발생합니다. typescript의 장점은 자바 스크립트에서 수동으로 확인할 내용을 컴파일러에 위임하고 nullable/non에 대한 또 다른 검사를 갖는 것입니다. -nullable 유형은 나에게 합리적으로 보입니다. 그런데 SaferTypeScript와 ClosureCompiler는 이미 그런 종류의 검사를 수행합니다.

공용체 유형을 사용하면 이에 대해 훨씬 더 간단한 사양을 가질 수 있습니다.
이제 기본 유형 'null'이 있다고 가정하고 'null' 및 'undefined'가 어떤 유형과도 호환되지 않는 '더 엄격한' 모드를 가질 수 있으므로 null 허용 값을 표현하려면 다음을 수행합니다.

var myNullableString: (null | string);
var myString = "hello";
myNullableString = myString //valid
myString = myNullableString // error null is not assignable to string;

'엄격 모드'가 활성화되면 typescript는 nullable이 아닌 모든 변수가 초기화되었는지 확인해야 하며 기본적으로 선택적 매개변수도 nullable인지 확인해야 합니다.

var myString: string; // error
var myNullableString: (null | string); // no error

function myString(param1: string, param2?: string) {
  // param1 is string
  // param2 is (null | string)
}

@fdecampredon +1

Facebook이 TypeScript 구문을 사용하지만 기본적으로 nullable이 아닌 유형을 사용하여 원래 게시물에서와 같이 (null | T) 대한 약어를 지원하는 Flow에 대한 IIRC - ?T 또는 T? .

var myString: string; // error

변수를 조건부로 초기화하려는 경우 잠재적으로 매우 성가실 수 있습니다. 예:

var myString: string;
if (x) {
myString = a;
} else if (y) {
myString = b;
} else {
myString = c;
}

예를 들어 Rust에서 이것은 컴파일러가 myString이 사용되기 전에 초기화된다는 것을 알 수 있는 한 괜찮습니다. 그러나 TypeScript의 추론은 현재 이것을 지원하지 않습니다.

솔직히 같은 일을 var myString = '' 대신 var myString: string 너무 많이 귀찮게하지 않지만, 규칙의 종류는 항상 수 있는지 확인하십시오.

@fdecampredon +1 - 이 아이디어가 매우 마음에

(null | string) 약칭은 ?string 가 좋습니다.
그리고 @johnnyreilly 는 컴파일 시간 확인일 뿐입니다.

합계 유형은 기본적으로 nullable이 아닌 유형을 매우 흥미로운 가능성으로 만듭니다. 기본적으로 non-nullable의 안전 속성은 과장될 수 없습니다. Sum 유형과 계획된 "if/typeof destructuring"(이를 무엇이라고 불러야 하는지 확실하지 않음)은 null 허용 및 null 허용이 아닌 API를 통합하는 데 유형을 안전하게 만듭니다.

그러나 기본적으로 형식을 nullable이 아닌 것으로 만드는 것은 기존의 거의 모든 타사 형식 정의 파일을 변경해야 하는 엄청난 변경 사항입니다. 나는 주요 변경 사항에 대해 100% 찬성하지만 아무도 야생에 있는 유형 정의를 업데이트할 수 없습니다.

이러한 정의에 대한 많은 합의가 ConfirmedTyped 리포지토리에 수집되는 것은 좋지만 이 기능에 대해서는 여전히 실질적인 우려가 있습니다.

@samwgoldman 아이디어는 nonImplicitAny 와 같은 특수 컴파일러 플래그 아래에만 nullable이 아닌 유형을 갖는 것입니다. 이 플래그의 이름은 strict 또는 nonNullableType 있습니다. 따라서 주요 변경 사항은 없습니다.

@fdecampredon DefinedTyped 에서와 같이 TypeScript가 아닌 라이브러리에 대한 유형 정의는 어떻습니까? 이러한 정의는 컴파일러에서 확인하지 않으므로 null을 반환할 수 있는 타사 코드는 올바르게 작동하려면 다시 주석을 달아야 합니다.

현재 "문자열 반환"으로 주석이 달려 있지만 때때로 null을 반환하는 함수에 대한 형식 정의를 상상할 수 있습니다. nonNullableType 'ed 코드에서 해당 함수에 의존했다면 컴파일러는 불평하지 않고(어떻게 그럴 수 있습니까?) 내 코드는 더 이상 null-safe하지 않습니다.

제가 빠트린게 없다면 이건 플래그로 켜고 끌 수 있는 기능이 아닌가 싶습니다. 이것은 상호 운용성을 보장하기 위한 전부 아니면 전무(all or nothing) 의미 변경인 것 같습니다. 나는 플래그 전환 기능이 발생할 가능성이 더 높다고 생각하기 때문에 잘못된 것으로 입증되어 기쁩니다.

제쳐두고, 아직 Facebook의 Flow 컴파일러에 대한 정보가 많지 않지만 프레젠테이션의 비디오 녹화에서 기본적으로 nullable이 아닌 것으로 보입니다. 그렇다면 적어도 여기에는 약간의 우선 순위가 있습니다.

확인의이 속기 있다고 가정하자 ? type 위해 type | null | undefined .

@fdecampredon DefinedTyped 에서와 같이 TypeScript가 아닌 라이브러리에 대한 유형 정의는 어떻습니까? 이러한 정의는 컴파일러에서 확인하지 않으므로 null을 반환할 수 있는 타사 코드는 올바르게 작동하려면 다시 주석을 달아야 합니다.

현재 "문자열 반환"으로 주석이 달려 있지만 때때로 null을 반환하는 함수에 대한 형식 정의를 상상할 수 있습니다. nonNullableType' 코드에서 해당 함수에 의존했다면 컴파일러는 불평하지 않고(어떻게 그럴 수 있었습니까?) 내 코드는 더 이상 null-safe하지 않습니다.

문제가 보이지 않습니다. 일부 정의 파일은 nonNullableType 모드에서 유효하지 않지만 대부분의 경우 좋은 라이브러리는 null 또는 undefined 를 반환하지 않습니다. 따라서 정의는 대부분의 경우 여전히 정확합니다.
어쨌든 나는 개인적으로 확인/수정 없이 확실히 유형이 지정된 정의를 거의 고를 수 없습니다. 일부 정의에 ? 접두사를 추가하는 데 약간의 추가 작업이 필요합니다.

제가 빠트린게 없다면 이건 플래그로 켜고 끌 수 있는 기능이 아닌가 싶습니다. 이것은 상호 운용성을 보장하기 위한 전부 아니면 전무(all or nothing) 의미 변경인 것 같습니다. 나는 플래그 전환 기능이 발생할 가능성이 더 높다고 생각하기 때문에 잘못된 것으로 입증되어 기쁩니다.

플래그 전환 기능을 사용할 수 없는 이유를 모르겠습니다. 규칙은 간단합니다.

• 일반 모드에서 ? string 는 string 하고 null 또는 undefined 는 모든 유형에 할당할 수 있습니다.
• nonNullableType 모드에서 ? string 는 string | null | undefined 와 동일하고 null 또는 undefined 는 null 또는 undefined 이외의 다른 유형에 할당할 수 없습니다.

플래그 전환 기능과의 비호환성은 어디에 있습니까?

언어의 의미를 바꾸는 플래그는 위험한 것입니다. 한 가지 문제는 효과가 잠재적으로 매우 비국소적이라는 것입니다.

function fn(x: string): number;
function fn(x: number|null): string;

function foo() {
    return fn(null);
}

var x = foo(); // x: number or x: string?

코드 조각을 보고 있는 사람이 유형 시스템을 "따라갈" 수 있고 만들어지는 추론을 이해할 수 있는 것이 중요합니다. 언어의 규칙을 변경하는 많은 플래그를 갖기 시작하면 이는 불가능해집니다.

할 수 있는 유일한 안전한 종류는 할당 가능성의 의미를 동일하게 유지하고 현재 noImplicitAny 작동하는 방식과 마찬가지로 플래그에 의존하지 않는 것과 오류가 있는 것을 변경하는 것입니다.

나는 그것이 레트로 호환성을 깨뜨릴 것이라는 것을 알고 있습니다. @RyanCavanaugh의 관점을 이해합니다. 그러나 flowtype을 사용 하면 솔직히 정말 귀중한 기능 맛본 후에는 그것이 결국 typescript의 일부가 되기를 바랍니다.

RyanCavanaugh의 의견에 추가하여 --> 내가 어딘가에서 읽은 것에서 ES7 사양/제안은 함수 오버로딩의 사용을 언급합니다(함수 이름은 같지만 입력 매개변수 데이터 유형이 다름). 이것은 Javascript에 매우 필요한 기능입니다.

흐름 문서에서 :

흐름은 null을 다른 유형의 일부가 아닌 고유한 값으로 간주합니다.

var o = null;
print(o.x); // Error: Property cannot be accessed on possibly null value

모든 유형 T는 ?T를 작성하여 null(및 정의되지 않은 관련 값)을 포함하도록 만들 수 있습니다.

var o: ?string = null;
print(o.length); // Error: Property cannot be accessed on possibly null or undefined value

[Flow] 일부 동적 유형 테스트의 효과 이해

(즉, TS 용어에서 유형 가드를 이해함)

var o: ?string = null;
if (o == null) {
  o = 'hello';
}
print(o.length); // Okay, because of the null check

제한 사항

• 앨리어싱의 가능성으로 인해 개체 속성에 대한 검사가 제한됩니다.

지역 변수 유형을 조정할 수 있는 것 외에도 Flow는 특히 확인과 사용 사이에 중간 작업이 없을 때 객체 속성 유형을 조정할 수도 있습니다. 그러나 일반적으로 개체의 앨리어싱은 이러한 추론 형식의 범위를 제한합니다. 개체 속성에 대한 검사는 별칭을 통해 해당 속성에 대한 쓰기로 무효화될 수 있고 정적 분석이 별칭을 정확하게 추적하기 어렵기 때문입니다.

• 유형 가드 스타일 검사는 개체 속성에 대해 중복될 수 있습니다.

[D] null 검사가 안전을 위해 충분하다는 것이 분명하더라도 코드의 다른 메서드에서 null 검사가 수행되기 때문에 null 허용 필드가 일부 메서드에서 null이 아닌 것으로 인식될 것으로 기대하지 마십시오. 런타임(예를 들어, 전자 메서드에 대한 호출은 항상 후자 메서드에 대한 호출을 따라온다는 것을 알고 있기 때문입니다).

• undefined 이(가) 선택되지 않았습니다.

null과 마찬가지로 정의되지 않은 값도 문제를 일으킬 수 있습니다. 불행히도 정의되지 않은 값은 JavaScript에서 어디에나 있으며 언어의 사용성에 심각한 영향을 미치지 않고는 이를 피하기가 어렵습니다. 예를 들어, 배열에는 요소에 대한 구멍이 있을 수 있습니다. 개체 속성을 동적으로 추가 및 제거할 수 있습니다. Flow는 이 경우에 절충점을 만듭니다. 정의되지 않은 지역 변수와 반환 값을 감지하지만 객체 속성 및 배열 요소 액세스로 인한 정의되지 않은 가능성은 무시합니다.

null 유형(및 물음표 속기)을 도입할 때 옵션이 동시에 추가되면 어떻게 될까요? 파일에 null 유형이 있으면 명령줄에 플래그가 없는 경우에도 컴파일러가 해당 파일에 대해 nullable이 아닌 모드로 전환됩니다. 아니면 너무 마법 같은 것입니까?

@jbondc가 좋은 것 같습니다. 그러나 문제는 모든 곳에서 ! 끝날 것이라는 것입니다 :p

It's tempting to want to change JavaScript but the reality is a 'string' is nullable or can be undefined.

이것은 무엇을 의미 하는가? js에는 정적 유형이 없습니다. 예, 문자열은 "nullable"이지만 번호를 지정할 수 있고 객체를 지정할 수 있고 fooable할 수 있다는 점을 잊지 맙시다. 모든 값은 모든 유형을 가질 수 있습니다.

따라서 자바스크립트 위에 정적 유형 시스템을 계층화할 때 정적 유형이 nullable인지 여부를 선택하는 것은 단지 설계상의 결정일 뿐입니다. 내가 보기에는 nullable이 아닌 형식이 더 나은 기본값인 것 같습니다. 예를 들어 지정된 형식 외에 null 값을 허용하기 위해 함수 서명을 원하는 경우가 일반적이기 때문입니다.

의미 체계에 대한 범위 변경을 유발하는 "use strict"와 같은 지시문은 이미 언어의 일부입니다. TypeScript에 "nullable이 아닌 유형 사용" 지시문을 사용하는 것이 합리적이라고 생각합니다.

@metaweta 충분하지 않다고 생각합니다. 예를 들어 _non null 모듈_이 nullable 모듈을 소비하면 어떻게 될까요?

//module A
export function getData(): string[] {
  return null;
}
//module B
'use nonnull'
import A = require('./A');

var data: string[] = A.getData();

모듈 B의 data 는 사실 nullable이지만 'use nonnull' 는 모듈 A에서 사용되지 않았기 때문에 오류를 보고해야 합니까?
지시문 기반 기능으로 그 문제를 해결할 방법이 없습니다.

네,

var data: string[] = A.getData();

오류가 발생합니다. 대신 getData() 이 null 반환할 때 기본값을 제공해야 합니다.

var data: string[] = A.getData() || [];

@metaweta ok 하지만 오류라는 것을 어떻게 압니까? :)
getData 유형은 여전히 ​​'() => string[]'입니다. 'nullable 모듈'에서 오는 모든 것을 'nullable'로 자동 처리하시겠습니까?

예, 정확합니다(nullable 모듈의 유형이 명시적으로 다르게 표시되지 않는 한).

이제 해당 파일이 기본적으로 nullable인지 여부를 나타내는 파일별 플래그가 필요한 것처럼 들립니다.

개인적으로 이 변경 사항을 도입 하기에는 조금 늦었다고 생각합니다.

프로젝트는 기본적으로 이 컴파일러 플래그를 설정하거나 해제한 상태로 시작합니까? 누군가가 기본 nullable이 아닌 프로젝트에서 작업하고 기본 nullable 프로젝트를 생성/전환하는 경우 혼란을 일으키나요?
저는 현재 대부분의 프로젝트에서 No Implicit Any로 작업하고 있으며 해당 옵션이 켜져 있지 않은 프로젝트를 볼 때마다 놀라움을 금치 못합니다.

암시적 없음은 좋지만 언어가 동작하는 방식을 변경하는 플래그의 관점에서 보면 그것이 라인이어야 한다고 생각합니다. 그 이상, 다른 규칙을 가진 다른 사람들이 시작한 여러 프로젝트에서 작업하는 사람들은 잘못된 가정과 실수로 인해 많은 생산성을 잃을 것입니다.

@RyanCavanaugh 는 비 지역성에 대해 우려했으며 지시문은 어휘 범위가 있습니다. 각 사이트에 주석을 달지 않으면 더 이상 로컬을 얻을 수 없습니다. 나는 특별히 이 지침에 찬성하지 않습니다. 나는 옵션이 존재하고 적어도 ES5에서 "use strict"만큼 합리적이라고 지적했습니다. 저는 개인적으로 기본적으로 nullable이 아닌 유형을 선호하지만 실제로는 너무 늦었습니다. 이러한 제약 조건을 감안할 때 저는 ! 어떻게 든. @jbondc 의 제안을 통해 null과 undefined를 구별할 수 있습니다. Java 백엔드가 계속해서 사람들이 두 값을 모두 사용하게 한다는 점을 감안할 때 가장 유용한 것 같습니다.

내가 명확하지 않은 경우 미안 해요, 나는 Ryan과 동의하고 내 자신의 우려를 추가했습니다.

솔직히 use not-null 추가하는 것이 모든 null 포인터 예외를 피하기 위한 대가라면 아무 문제 없이 지불할 것입니다. null 또는 undefined 를 모든 유형에 할당할 수 있다고 생각하면 더 나쁜 오류입니다. 내 생각에 만든 그 활자.

@jbondc 저는 '엄격한 사용'을 사용하지 않았으므로 몇 가지 가정을 하고 있습니다. 제 가정이 잘못된 경우 수정해 주세요.

Not null은 프로그래머가 작성하는 구문에 영향을 미치지 않지만 해당 코드를 사용하려고 시도하는 다음 프로그래머의 기능(생성자와 사용자가 별개의 사람이라고 가정)에 영향을 줍니다.

그래서 코드:

function myfoo (mynumber: number) {
    return !!mynumber;
} 

(핸드폰으로 쓰다보니 틀릴 수 있음)
일반 프로젝트와 notnull 프로젝트 모두에서 유효한 코드입니다. 코더가 코드가 작동하는지 여부를 알 수 있는 유일한 방법은 명령줄 인수를 보는 것입니다.

직장에는 테스트 프로젝트(새로운 기능의 프로토타입 제작 포함)와 메인 프로젝트(실제 코드 포함)가 있습니다. 프로토타입이 한 프로젝트에서 다른 프로젝트로 이동할 준비가 되면(일반적으로 대형 굴절기가 있는 경우) 코드에는 오류가 없지만 코드 사용에는 오류가 있습니다. 이 동작은 암시적 없음과 다르며 둘 다 즉시 오류가 발생하는 strict를 사용합니다.

이제 이 프로젝트에서 상당한 영향력을 행사하고 있으므로 담당자에게 이 새로운 '기능'을 사용하지 말라고 경고할 수 있습니다. 왜냐하면 시간을 절약할 수 없기 때문입니다. 일하다.
하나의 프로젝트에서도 이 기능을 활성화하려면 다른 모든 프로젝트에서 활성화해야 합니다. 왜냐하면 프로젝트 간에 코드 공유와 코드 마이그레이션이 매우 많기 때문입니다. 이 '기능'으로 인해 많은 문제가 발생합니다. 시간을 되돌리고 이미 완료된 기능을 '고정'합니다.

맞습니다 @jbondc. @Griffork : 그 오해를 잡지 못해서 죄송합니다. 지시문은 프로그램 생성 또는 함수 생성의 첫 번째 행으로 나타나는 리터럴 문자열 표현식이며 그 효과는 해당 생성으로 범위가 지정됩니다.

"use not-null";
// All types in this program production (essentially a single file) are not null

~ 대

function f(n: number) {
  "use not-null";
  // n is not null and local variables are not null
  function g(s: string) {
    // s is not null because g is defined in the scope of f
    return s.length;
  }
  return n.toFixed(2);
}

function h(n: number) {
  // n may be null
  if (n) { return n.toFixed(3); }
  else { return null; }
}

nullable이 아닌 유형은 쓸모가 없습니다. nullable이 아닌 유형은 유용합니다. 그들은 쓸모가 없습니다. 쓸모없는! 당신은 그것을 깨닫지 못하지만 당신은 그것들이 정말로 필요하지 않습니다. 이제부터 NULL을 사용하지 않을 것이라고 선언함으로써 자신을 제한하는 것은 거의 의미가 없습니다. 예를 들어 존재하지 않는 부분 문자열을 찾으려고 할 때 누락된 값을 어떻게 나타낼 수 있습니까? 누락된 값(현재 NULL이 수행하는 작업)을 표현할 수 없다고 해서 문제가 해결되지는 않습니다. 당신은 결측값이 전혀 없는 똑같이 가혹한 세상을 위해 모든 곳에서 NULL이 있는 가혹한 세상을 교환할 것입니다. 당신이 정말로 필요로 하는 것은 (다른 많은 멋진 것들 중에서) 누락된 값(처음에 찾고 있는 것과 명령형 세계에서 NULL로 표현되는 것)을 나타내는 기능을 갖춘 대수적 데이터 유형 입니다. 나는 언어에 non-nullables를 추가하는 것을 강력히 반대 합니다. 왜냐하면 그것은 잘 알려진 문제에 대한 순진하고 어색한 해결책인 쓸모없는 구문/의미 쓰레기처럼 보이기 때문입니다. F#의 Optionals 및 Haskell의 Maybe, 변종(일명 태그가 있는 공용체, 판별 공용체) 및 패턴 일치에 대해 읽어보세요.

@aleksey-bykov JavaScript에 undefined 및 null 두 가지 null 값이 있다는 것을 모르는 것 같습니다. JavaScript의 null 값은 일치하지 않는 정규 표현식과 JSON에서 날짜를 직렬화할 때만 반환됩니다. 그것이 언어로 된 유일한 이유는 Java 애플릿과의 상호 작용 때문입니다. 선언되었지만 초기화되지 않은 변수는 undefined 가 아니라 null 입니다. 개체의 속성이 없으면 null 아니라 undefined 반환합니다. undefined 가 유효한 값이 되도록 명시적으로 원하는 경우 propName in obj 테스트할 수 있습니다. 속성이 상속되었는지 여부가 아니라 객체 자체에 속성이 있는지 확인하려면 obj.hasOwnProperty(propName) . 누락된 하위 문자열은 -1을 반환합니다: 'abc'.indexOf('d') === -1 .

Haskell에서 Maybe는 보편적인 하위 유형이 없기 때문에 유용합니다. Haskell의 하단 유형은 범용 하위 유형이 아니라 비종료를 나타냅니다. 대수 데이터 유형이 필요하다는 데 동의하지만 정수로 레이블이 지정된 트리를 원하면 모든 노드가 null 또는 undefined 가 아닌 정수를 갖기를 원합니다. 만약 내가 그것들을 원한다면, 나는 Maybe int나 지퍼로 레이블이 붙은 나무를 사용할 것이다.

"use not-null" 지시어를 채택한다면 "use not-void"(null도 undefined도 아님)도 원합니다.

null에서 자신의 코드를 보장하려면 null을 금지하십시오.
리터럴. nullable이 아닌 유형을 개발하는 것보다 훨씬 쉽습니다. 정의되지 않은 것은
조금 더 복잡하지만 그것들이 무엇에서 왔는지 안다면
당신은 그들을 피하는 방법을 알고 있습니다. Haskell의 바닥은 매우 중요합니다! 나는 원한다
JavaScript(TypeScript)에는 값이 없는 전역 수퍼 유형이 있습니다. 나는 그것이 그립다
내가 표현을 던져야 할 때 심하게. 나는 TypeScript를 사용하고 있습니다
v 0.8 이후로 null이 필요한 것은 고사하고 null을 사용하지 않았습니다. 그냥 무시해
with 와 같은 다른 쓸모없는 언어 기능과 마찬가지로
성명.

@aleksey-bykov 라이브러리를 작성 중이고 입력이 null이 아님을 보장하려면 모든 곳에서 런타임 테스트를 수행해야 합니다. 나는 그것을 위한 컴파일 타임 테스트를 원하는데 제공하기 어렵지 않으며 Closure와 Flow는 모두 non-null/undefined 유형에 대한 지원을 제공합니다.

@metaweta , null로부터 자신을 보장할 수 없습니다. 코드가 컴파일되기 전에 lib를 울리는 pleaseNonNullablesNumbersOnly(<any> null) 같은 수많은 방법이 있습니다. js로 컴파일한 후에는 규칙이 전혀 없습니다. 둘째, 왜 신경을 쓰겠습니까? nulls are not supported, you put a null you will get a crash 면책 조항처럼 크고 명확하게 말하세요. 모든 부류의 사람들로부터 자신을 보장할 수는 없지만 책임 범위를 대략적으로 설명할 수 있습니다. 셋째, 사용자가 입력으로 입력할 수 있는 모든 것에 방탄인 주요 주류 라이브러리는 거의 생각할 수 없지만 여전히 미친 인기를 얻고 있습니다. 그렇다면 당신의 노력은 문제가 될 만한 가치가 있습니까?

@aleksey-bykov 내 라이브러리의 클라이언트도 유형 검사를 받는다면 null이 발생하지 않을 것이라고 확실히 보장할 수 있습니다. 이것이 TypeScript의 요점입니다. 당신의 추론에 따르면 유형이 전혀 필요하지 않습니다. 예상 유형이 무엇인지 문서에서 "크고 명확하게 말하십시오".

주제에서 벗어나 null을 확인하는 것이 undefined에 대해 확인하는 것보다 빠르기 때문에 null은 매우 중요합니다.
모든 곳에서 사용하지는 않지만 초기화되지 않은 값과 누락된 숫자를 나타내기 위해 가능한 한 사용하려고 합니다.

주제:
null이 다른 코드로 '이스케이프'되는 문제는 없었지만 임의의 undefinedes 또는 NaN이 나타나는 문제가 있었습니다. 이 시나리오에서는 플래그보다 신중한 코드 관리가 더 낫다고 생각합니다.

그러나 라이브러리 타이핑의 경우 null을 반환할 수 있는 함수에 주석을 추가하도록 선택할 수 있도록 중복 유형 null이 있으면 좋을 것입니다(이는 컴파일러에 의해 적용되지 않고 코딩 방식에 의해 적용되어야 함).

@metaweta , 내 추론에 --noNullLiteral 를 추가합니다. 다른 모든 것은 그대로 유지되고 동일한 코드로 걱정할 필요가 없으며 최소한의 설치 공간으로 더 가벼운 솔루션입니다. 내 요점으로 돌아가서 null을 허용하지 않는 유형이 TS에 도달하고 2가지 다른 방식으로 사용 가능하다고 가정합니다.

• ! 구문을 사용하여 null을 사용할 수 없는 유형을 나타낼 수 있습니다. 예를 들어 string! 는 null을 사용할 수 없습니다.
• noNullsAllowed 스위치가 켜져 있습니다.

그런 다음 모든 곳에서 null이있는 ajax를 통해 서버에서 json 조각을 얻습니다. 도덕적 : 자바 스크립트의 동적 특성은 그 위에 유형 주석으로 수정할 수 없습니다.

@aleksey-bykov 같은 토큰으로 숫자 속성 x 있는 개체를 기대하고 서버에서 {"x":"foo"} 를 받으면 유형 시스템에서 이를 방지할 수 없습니다. . 이는 서버에서 TypeScript 이외의 것을 사용할 때 반드시 런타임 오류이자 피할 수 없는 문제입니다.

그러나 서버가 TypeScript로 작성되고 노드에서 실행되는 경우 내 프런트 엔드 코드에 대한 .d.ts 파일이 있는 상태에서 변환될 수 있으며 유형 검사는 서버가 null을 포함하는 JSON을 보내지 않도록 보장합니다. 그 안에 있거나 x 속성이 숫자가 아닌 객체.

@metaweta , nullable이 아닌 유형은 확실히 또 다른 유형 안전 조치가 될 것입니다. 저는 의심의 여지가 없습니다. 매우 기본적인 원칙을 부과함으로써(코드에서 null 리터럴을 피함) 요구하지 않고 문제의 90%를 제거할 수 있습니다. 컴파일러의 도움. 이 조치를 시행할 수 있는 충분한 자원이 있다고 해도 나머지 10%의 문제를 제거할 수는 없습니다. 결국 질문은 무엇입니까? 나는 묻습니다. 우리는 그것이 정말로 그렇게 필요합니까? 그렇지 않습니다. null 없이 성공적으로 사는 방법을 배웠습니다. 우리가 갖고 싶은 더 멋진 것들이 있습니다. 이 특별한 것은 너무 중요하지 않습니다.

예, 우리는 이것이 절실히 필요합니다. Hoare 의 10억 달러 실수 를 참조하십시오. NPE(널 포인터 예외)는 nullable 형식과 nullable이 아닌 형식을 구별하지 않는 형식화된 프로그래밍 언어에서 발생하는 가장 일반적인 오류입니다. 너무 일반적이어서 Java 8은 이에 맞서기 위해 필사적으로 Optional 를 추가했습니다.

유형 시스템에서 nullable을 모델링하는 것은 이론적인 문제일 뿐만 아니라 엄청난 개선입니다. 코드에서 null을 피하기 위해 각별한 주의를 기울이더라도 사용하는 라이브러리는 그렇지 않을 수 있으므로 유형 시스템으로 데이터를 적절하게 모델링할 수 있는 것이 유용합니다.

이제 TS에 공용체와 유형 가드가 있으므로 유형 시스템은 이를 수행할 수 있을 만큼 강력합니다. 문제는 그것이 이전 버전과 호환되는 방식으로 수행될 수 있는지 여부입니다. 개인적으로 이 기능은 TypeScript 2.0이 이와 관련하여 이전 버전과 호환되지 않을 만큼 충분히 중요하다고 생각합니다.

이 기능을 적절하게 구현하면 기존 코드를 깨뜨리기 보다는 이미 손상된 코드를 가리킬 가능성이 높습니다. 이는 단순히 외부에서 null을 누출하는 함수(대부분 의도치 않게) 또는 해당 멤버를 제대로 초기화하지 않는 클래스(이 부분)를 가리킬 것입니다. 형식 시스템이 생성자에서 초기화되는 멤버 값을 허용해야 할 수도 있기 때문에 더 어렵습니다).

이것은 null을 _사용하지 않는_에 관한 것이 아닙니다. 관련된 모든 유형을 적절하게 모델링하는 것입니다. 사실 이 기능은 안전한 방법으로 null을 사용할 수 있게 해줍니다. 더 이상 null을 피할 이유가 없습니다! 최종 결과는 대수적 Maybe 유형의 패턴 일치와 매우 유사합니다(케이스 표현식이 아닌 if 검사로 수행된다는 점을 제외하고).

그리고 이것은 단지 null 리터럴에 관한 것이 아닙니다. null 및 undefined 는 구조적으로 동일하므로(하나에서는 작동하지만 다른 하나에서는 작동하지 않는 함수/연산자가 없음) TS에서 단일 null 유형으로 충분히 잘 모델링될 수 있습니다.

@메타웨타 ,

JavaScript의 null 값은 일치하지 않는 정규 표현식과 JSON에서 날짜를 직렬화할 때만 반환됩니다.

전혀 사실이 아닙니다.

• DOM과의 상호 작용은 null을 생성합니다.

  console.log(window.document.getElementById('nonExistentElement')); // null

• @aleksey-bykov가 위에서 지적했듯이 ajax 작업은 null을 반환할 수 있습니다. 실제로 undefined 는 유효한 JSON 값이 아닙니다.

 JSON.parse(undefined); // error
 JSON.parse(null); // okay
 JSON.stringify({ "foo" : undefined}); // "{}"
 JSON.stringify({ "foo" : null}); // '{"foo":null}'

NB: 존재하지 않는 속성에 액세스하면 undefined 가 발생하기 때문에 undefined 가 ajax를 통해 반환되는 척 할 수 있습니다. 이것이 undefined가 직렬화되지 않는 이유입니다.

그러나 서버가 TypeScript로 작성되고 노드에서 실행되는 경우 내 프런트 엔드 코드에 대한 .d.ts 파일이 있는 상태에서 변환될 수 있으며 유형 검사는 서버가 null을 포함하는 JSON을 보내지 않도록 보장합니다. 그 안에 있거나 x 속성이 숫자가 아닌 객체.

이것은 완전히 정확하지 않습니다. 서버가 TypeScipt로 작성되더라도 영구 저장소에서 얻은 모든 단일 개체의 모든 단일 속성을 확인하지 않고 null이 도입되는 것을 보장할 수 없습니다.

나는 이것에 대해 @aleksey-bykov에 동의합니다. TypeScript가 null 및 undefined에 의해 발생하는 오류에 대해 컴파일 시간에 우리에게 경고하도록 할 수 있다면 절대적으로 훌륭할 것이지만, null의 실제 소스가 감지되지 않는 동안 잘못된 확신을 유도하고 사소한 잡담으로 끝날까봐 두렵습니다.

서버가 TypeScipt로 작성되더라도 영구 저장소에서 얻은 모든 단일 개체의 모든 단일 속성을 확인하지 않고 null이 도입되는 것을 보장할 수 없습니다.

이것은 사실 nullable이 아닌 _for_ 인수입니다. 저장소가 null Foo를 반환할 수 있는 경우 해당 저장소에서 검색된 개체 유형은 Foo가 아니라 Nullable<Foo>입니다. 그런 다음 Foo를 반환하도록 되어 있는 반환 함수가 있는 경우 null을 처리하여 책임을 _가지고_ 있습니다.

nullable이 아닌 유형이 없다면 저장된 객체를 반환할 때 null을 확인해야 한다고 생각하지 않을 것입니다.

null의 실제 소스가 감지되지 않은 상태에서 잘못된 자신감을 불러일으키고 사소한 정보를 얻게 될까봐 두렵습니다.

nullable이 아닌 유형이 놓칠 수 있는 사소한 유형은 무엇이라고 생각합니까?

이것은 완전히 정확하지 않습니다. 서버가 TypeScipt로 작성되더라도 영구 저장소에서 얻은 모든 단일 개체의 모든 단일 속성을 확인하지 않고 null이 도입되는 것을 보장할 수 없습니다.

영구 저장소가 유형 데이터를 지원하는 경우 필요하지 않습니다. 그러나 그렇지 않은 경우에도 데이터 가져오기 지점에서만 검사를 수행한 다음 다른 코드의 _모든_ 전체에 대해 보증을 하게 됩니다.

나는 이것에 대해 @aleksey-bykov에 동의합니다. TypeScript가 null 및 undefined에 의해 발생하는 오류에 대해 컴파일 시간에 우리에게 경고하도록 할 수 있다면 절대적으로 훌륭할 것이지만, null의 실제 소스가 감지되지 않는 동안 잘못된 확신을 유도하고 사소한 잡담으로 끝날까봐 두렵습니다.

nullable 형식을 사용하는 것은 절대적인 요구 사항이 아닙니다. 메서드가 null을 반환하는 경우가 "무의미한" 경우를 모델링하는 것이 불필요하다고 생각되면 해당 형식 정의에서 nullable 형식을 사용할 수 없으며 항상 동일한 안전하지 않음을 얻을 수 있습니다. 그러나 이 접근 방식이 실패할 것이라고 생각할 이유가 없습니다. 이미 성공적으로 구현한 언어의 예가 있습니다(예: JetBrains의 Kotlin ).

@aleksey-bykov 솔직히 말해서 완전히 틀렸습니다. nullable이 아닌 유형의 가장 좋은 점 중 하나는 _유형을 nullable로 표현할 수 있는 가능성입니다.
null 포인터 오류를 방지하기 위해 null을 사용하지 않는 전략을 사용하면 오류 도입에 대한 두려움에서 null 를 사용할 가능성을 완전히 잃게 됩니다. 이는 완전히 어리석은 일입니다.

언어 기능에 대한 토론에서 다음과 같은 어리석은 의견과 함께 가지 마십시오.

nullable이 아닌 유형은 쓸모가 없습니다. nullable이 아닌 유형은 유용합니다. 그들은 쓸모가 없습니다. 쓸모없는! 당신은 그것을 깨닫지 못하지만 당신은 그것들이 정말로 필요하지 않습니다.

그것은 당신이 웹에 게시할 모든 것을 무시해야 한다는 생각이 들게 합니다. 우리는 기능에 대해 논의하기 위해 여기 있습니다. 나는 당신의 관점이 나의 관점이 아니라는 것을 이해하고 기꺼이 받아들일 수 있습니다. 그러나 다음과 같이 행동하지 마십시오 어린이.

나는 null이 아닌 유형의 주석을 도입하는 것에 전혀 반대하지 않습니다. C# 및 기타 언어에서 유용한 것으로 나타났습니다.

OP는 다음과 같이 토론 과정을 변경했습니다.

솔직히 null이 아닌 사용을 추가하는 것이 모든 null 포인터 예외를 피하기 위한 대가라면 문제 없이 지불할 것입니다. null 또는 undefined를 모든 유형에 할당할 수 있는 것으로 고려하는 것은 내 생각에 typescript가 만든 더 나쁜 오류입니다.

나는 단지 야생에서 null 및 undefined 의 유행을 지적한 것입니다.

TypeScript에 대해 진정으로 감사하는 것 중 하나는 언어의 자유방임적인 태도입니다. 신선한 공기를 마시게 되었습니다.

유형이 기본적으로 null을 허용하지 않는다고 주장하는 것은 그 정신에 어긋납니다.

나는 왜 우리가 이것을 필요로 하는지/필요하지 않은지에 대해 떠도는 수많은 논쟁을 보아왔고 지금까지 논의된 모든 기본 사례를 이해하고 있는지 확인하고 싶습니다.

1) 함수가 null을 반환할 수 있는지 여부를 알고 싶습니다(입력이 아니라 실행 패턴으로 인해 발생함).
2) 값이 null일 수 있는지 알고 싶습니다.
3) 데이터 개체에 null 값이 포함될 수 있는지 알고 싶습니다.

이제 상황 2가 발생할 수 있는 두 가지 경우가 있습니다. 즉, null을 사용하거나 함수가 null을 반환하는 경우입니다. 코드에서 모든 null을 제거하면(원하지 않는다고 가정) 실제로 상황 2는 상황 1의 결과로만 발생할 수 있습니다.

상황 1 null 값의 존재를 표시하기 위해 함수의 반환 유형에 주석을 추가하여 가장 잘 해결된다고 생각합니다. _널이 아닌 유형이 필요하다는 의미는 아닙니다_. 함수에 주석을 달 수 있고(예: 공용체 유형을 사용하여) null이 아닌 유형이 없을 수 있습니다. 이는 문서와 비슷하지만 이 경우 더 명확할 수 있습니다.

솔루션 2도 이것으로 해결됩니다.

이를 통해 회사에서 일하는 프로그래머는 프로세스와 표준을 사용하여 Typescript 팀이 아닌 null 유형이 마크업되도록 할 수 있습니다(전체 타이핑 시스템이 옵트인되는 것과 똑같은 방식이므로 명시적 nullable 유형이 opt가 되어야 합니다. 에).

시나리오 3의 경우 서버와 클라이언트 사이의 계약은 Typescript가 강제하는 것이 아니므로 영향을 받는 값을 null 가능성으로 마크업할 수 있으면 개선될 수 있지만 결국에는 typescript와 동일한 보장을 받게 됩니다. 도구는 다른 모든 가치를 제공합니다(즉, 좋은 코딩 표준이나 관행이 없으면 아무 가치도 없습니다!

(전화로 올린 글이라 오류 죄송합니다)

@fdecampredon , 처음부터 두려움이 아니라 null을 사용할 필요가 없다는 것입니다. 나는 그것들이 필요하지 않습니다. 좋은 보너스로 null 참조 예외 문제가 제거되었습니다. 어떻게 모든 것이 가능합니까? 빈 경우에 sum-type을 사용하여. 합계 유형은 F#, Scala, Haskell 및 대수 데이터 유형이라는 제품 유형과 함께 모든 FP 언어의 기본 기능입니다. 대소문자가 비어 있는 합계 유형의 표준 예는 F#의 Optional 및 Haskell의 Maybe입니다. TypeScript에는 ADT가 없지만 그 대신 ADT에서 다룰 수 있는 한 가지 특별한 경우를 모델링하는 non-nullable 추가에 대한 논의가 진행 중입니다. 그래서 제 메시지는 ADT에 대해 non-nullable을 버리라는 것입니다.

@spion , 나쁜 소식: F#에 null이 있습니다(.NET의 레거시로). 좋은 소식: 아무도 사용하지 않습니다. null이 있을 때 어떻게 사용하지 않을 수 있습니까? 그들은 선택 사항이 있습니다 (당신이 언급 한 가장 최근의 Java와 마찬가지로). 따라서 더 나은 선택이 가능하다면 null이 필요하지 않습니다. 이것이 내가 궁극적으로 제안하는 것입니다. null(null이 아닌)은 그대로 두고, 존재한다는 사실을 잊고, ADT를 언어 기능으로 구현하십시오.

우리는 null을 사용하지만 사람들이 사용하는 것과 같은 방식은 아닙니다. 내 회사 소스 코드는 두 부분으로 제공됩니다.

1) 데이터(데이터베이스 데이터와 같은)의 경우 변수 선언 시 null을 공백 데이터로 대체합니다.

2) 프로그래밍 가능한 개체와 같은 다른 모든 개체는 null을 사용하여 필요한 자바스크립트 개체가 아닌 개체가 생성되지 않거나 할당할 수 없는 소스 코드에 버그와 허점이 있는 경우를 알 수 있습니다. undefined는 소스 코드에 버그나 허점이 있는 자바스크립트 객체 문제입니다.

null 허용을 원하지 않는 데이터는 고객 데이터이므로 null 문구가 표시됩니다.

@aleksey-bykov typescript 에는 공용체 유형

다른 쪽 끝에는 null 값을 제외하는 공용체 유형을 정의하는 것이 불가능하기 때문에 null이 아닌 유형이 필요합니다.

@fdecampredon , TS에는 ADT가 없고 합 유형이 아닌 공용체가 있습니다. 왜냐하면 당신이 말했듯이 1. 단위 유형이 없기 때문에 빈 케이스를 올바르게 모델링할 수 없기 때문입니다. 2. 신뢰할 수 있는 구조 해제 방법이 없습니다. 그들을

ADT에 대한 패턴 일치는 생성된 JavaScript와 밀접하게 정렬되는 방식으로 구현될 수 있습니다. 어쨌든 이 인수가 전환점이 아니기를 바랍니다.

@aleksey-bykov 이것은 F#이 아닙니다. JavaScript 유형을 모델링하는 것을 목표로 하는 언어입니다. JavaScript 라이브러리는 null 및 정의되지 않은 값을 사용합니다. 따라서 해당 값은 적절한 유형으로 모델링해야 합니다. ES6조차도 대수 데이터 유형을 지원하지 않기 때문에 TypeScript의 설계 목표를 감안할 때 해당 솔루션을 사용하는 것은 의미가 없습니다.

또한 JavaScript 프로그래머는 일반적으로 패턴 일치 대신 if 검사(typeof 및 동등성 테스트와 함께)를 사용합니다. 이들은 이미 TypeScript 공용체 유형을 좁힐 수 있습니다. 이 시점에서 대수적 Maybe 등과 비슷한 이점을 가진 nullable이 아닌 유형을 지원하는 것은 작은 단계일 뿐입니다.

lib.d.ts 에 도입해야 할 수 있는 엄청난 변경 사항과 생성자 호출 중 클래스 필드의 일시적인 null 상태의 잠재적인 문제에 대해 아무도 언급하지 않았다는 사실에 놀랐습니다. 이는 nullable이 아닌 유형을 구현하기 위한 실제적이고 실제적인 잠재적인 문제입니다...

@Griffork 아이디어는 코드의 모든 곳에서 null 검사를 피하는 것입니다. 다음 기능이 있다고 가정해 보겠습니다.

declare function getName(personId:number):string|null;

아이디어는 이름이 null인지 여부를 한 번만 확인하고 null 검사를 추가해야 한다는 걱정 없이 나머지 코드를 모두 실행한다는 것입니다.

function doSomethingWithPersonsName(personId:number) {
  var name = getName(personId);
  if (name != null) return doThingsWith(name); // type guard narrows string|null to just string
  else { return handleNullCase(); }
}

이제 당신은 훌륭합니다! 유형 시스템은 doThingsWith 가 null이 아닌 이름으로 호출되도록 보장합니다.

function doThingsWith(name:string) {
  // Lets create some funny versions of the name
  return [uppercasedName(name), fullyLowercased(name), funnyCased(name)]
}

이러한 함수는 null을 확인할 필요가 없으며 코드는 throw 없이 계속 작동합니다. 그리고 이러한 함수 중 하나에 nullable 문자열을 전달하려고 하면 유형 시스템에서 즉시 오류를 알려줍니다.

function justUppercased(personId:number) {
  var name = getName(personId);
  return uppercasedName(name); // error, passing nullable to a function that doesn't check for nulls.
}

이것은 엄청난 이점입니다. 이제 유형 시스템은 함수가 nullable 값을 처리할 수 있는지 여부를 추적하고 더 나아가 실제로 필요한지 여부를 추적합니다. 훨씬 더 깨끗한 코드, 더 적은 검사, 더 많은 안전성. 그리고 이것은 단지 문자열에 관한 것이 아닙니다. 런타임 유형 검사 와 같은 라이브러리를 사용하면 훨씬 더 복잡한 데이터에 대한 유형 가드를 구축할 수도 있습니다.

null 값의 가능성을 모델링할 가치가 없다고 느끼기 때문에 추적이 마음에 들지 않으면 이전의 안전하지 않은 동작으로 되돌릴 수 있습니다.

declare function getName(personId:number):string;

그런 경우 typescript는 분명히 잘못된 작업을 수행하는 경우에만 경고합니다.

uppercasedName(null);

솔직히 이전 버전과의 호환성을 제외하고는 단점이 보이지 않습니다.

@jbondc https://github.com/Microsoft/TypeScript/issues/186 이 하나

@fdecampredon Union 유형은 바로 Union입니다. 그들은 _disjoint_ 통합(합계)이 아닙니다. #186 참조.

@aleksey-bykov

옵션 유형을 추가하는 것은 여전히 ​​주요 변경 사항입니다.

// lib.d.ts
interface Document {
    getElementById(id: string): Maybe<Element>;
}

...

// Code that worked with 1.3
var myCanvas = <HTMLCanvasElement>document.getElementById("myCanvas");
// ... now throws the error that Maybe<Element> can't be cast to an <HTMLCanvasElement>

결국 Destructuring을 통해 지금 가난한 사람의 옵션 유형을 얻을 수 있습니다.

class Option<T> {
    hasValue: boolean;
    value: T;
}

var { hasValue, myCanvas: value } = <Option<HTMLCanvasElement>> $("myCanvas");
if (!hasValue) {
    throw new Error("Canvas not found");
}
// Use myCanvas here

그러나 이것의 유일한 값은 lib.d.ts(및 다른 .d.ts, 전체 코드베이스, 그러나 우리는 그것을 고칠 수 있다고 가정할 것입니다)도 그것을 사용하는 경우입니다. 그렇지 않으면 다시 Option을 사용하지 않는 함수는 코드를 확인하지 않는 한 null을 반환하거나 반환하지 않을 수 있습니다.

또한 기본적으로 null이 아닌 유형을 선호하지 않습니다(TS 1.x는 그렇지 않음). 너무 큰 브레이킹 체인지입니다.

그러나 우리가 2.0에 대해 이야기하고 있다고 가정해 봅시다. 어쨌든 주요 변경 사항이 있는 경우(옵션 유형 추가) 기본적으로 유형도 null을 허용하지 않도록 설정하지 않는 이유는 무엇입니까? 기본적으로 유형을 nullable이 아닌 것으로 만들고 옵션 유형을 추가하는 것은 배타적이지 않습니다. 후자는 독립형일 수 있지만(예: 지적한 대로 F#에서) 전자는 후자가 필요합니다.

@Arnavion , 약간의 오해가 있습니다. 서명을 교체해야 한다고 말하지 않았습니다. 기존의 모든 서명은 그대로 유지됩니다. 새로운 개발을 위해서는 ADT를 사용하거나 원하는 모든 것을 자유롭게 사용할 수 있습니다. 따라서 주요 변경 사항이 없습니다. 기본적으로 null이 아닌 것은 없습니다.

ATD가 여기에 있는 경우 null이 다음을 선택 사항으로 변환하여 응용 프로그램으로 누출될 수 있는 모든 위치를 래핑하는 것은 개발자의 몫입니다. 이것은 독립 실행형 프로젝트에 대한 아이디어가 될 수 있습니다.

@aleksey-bykov

서명을 교체해야 한다고 말하지 않았습니다. 기존 서명은 모두 그대로 유지됩니다.

_I_는 서명을 교체해야 한다고 말했고 이미 이유를 밝혔습니다.

그러나 이것의 유일한 값은 lib.d.ts(및 다른 .d.ts, 전체 코드베이스, 그러나 우리는 그것을 고칠 수 있다고 가정할 것입니다)도 그것을 사용하는 경우입니다. 그렇지 않으면 다시 Option을 사용하지 않는 함수는 코드를 확인하지 않는 한 null을 반환하거나 반환하지 않을 수 있습니다.

기본적으로 null이 아닌 것은 없습니다. 항상.

TS 1.x의 경우 너무 큰 주요 변경 사항이기 때문에 동의합니다. 2.0의 경우 기본 서명(lib.d.ts 등)에서 옵션 유형을 사용하는 것은 이미 주요 변경 사항입니다. 기본적으로 유형을 nullable이 아닌 것으로 만드는 것은 _그 외에도_ 가치가 있으며 단점이 없습니다.

나는 동의하지 않습니다. 옵셔널을 도입한다고 해서 아무 것도 깨져서는 안 됩니다. 우리가 옵셔널이나 nullable 또는 non-nullable을 사용하는 것과는 다릅니다. 누구나 원하는 것을 사용합니다. 기존 방식이 새로운 기능에 의존해서는 안 됩니다. 즉각적인 필요에 적합한 도구를 사용하는 것은 개발자의 몫입니다.

그래서 당신은 내가 Option<number>를 반환하는 함수 foo와 숫자를 반환하는 함수 막대가 있는 경우 내가 bar의 구현을 보거나 문서를 유지 관리하지 않는 한 bar가 null을 반환할 수 없다고 확신할 수 없다고 말하는 것입니다. "이 함수는 null을 반환하지 않습니다."? 이것이 null을 반환하지 않는 함수를 처벌한다고 생각하지 않습니까?

귀하의 예제에서 bar 함수는 시간의 구걸에서 nullable로 알려져 있었고, 약 100500개의 응용 프로그램에서 사용되었으며 모두가 결과를 nullable로 처리했습니다. 이제 당신은 와서 내부를 살펴보고 null 불가능합니다. 서명을 nullable에서 non-nullable로 변경해야 한다는 뜻입니까? 나는 당신이해서는 안된다고 생각합니다. 이 지식은 가치가 있지만 100500 애플리케이션을 중단할 가치가 없기 때문입니다. 당신이 해야 할 일은 다음과 같이 수정된 서명이 있는 새 라이브러리를 만드는 것입니다.

old_lib.d.ts

...
declare function bar(): number; // looks like can return a potentially nullable number
...

수정된_lib.d.ts

declare function bar(): !number; // now thank to the knowledge we are 100% certain it cannot return null

이제 기존 앱은 계속 old_lib.d.ts 를 사용합니다. 새 앱의 경우 개발자는 자유롭게 revised_libs.d.ts 를 선택할 수 있습니다.

불행히도 registered_libs.d.ts에는 내가 아직 보지 않은 50개의 다른 함수가 있습니다. 이 함수는 모두 숫자를 반환합니다. 지금 무엇?

자, 시간을 내어 도움을 요청하고 버전 관리를 사용하십시오(지금까지 얻은 지식 수준에 따라 계속 증가하는 버전 번호로 점진적으로 릴리스할 수도 있습니다: revised_lib.v-0.1.12.d.ts ).

실제로는 필요하지 않습니다. 서명에서는 nullable 형식을 반환하지만 구현에서는 nullable이 아닌 형식을 반환하는 함수는 호출자에 의한 중복 오류 검사만 발생합니다. 안전을 위협하지 않습니다. 점점 더 많은 기능에 ! 당신이 말했듯이 당신이 그들을 발견하면 잘 작동합니다.

나는 팬이 아니다! 입력해야 할 짐이 더 많기 때문입니다(키 입력과 사용을 기억해야 하는 측면 모두에서). 1.x에서 null 허용 여부를 원하면 ! 은 이미 위에서 논의한 옵션 중 하나이지만 2.0에서 궁극적인 주요 변경 사항이 있고 null 허용 여부를 기본값으로 설정하는 것이 가치가 있다고 여전히 말하고 싶습니다.

반면에 Python 2/3과 유사한 상황으로 이어질 수도 있습니다. 아무도 TS 2.0으로 몇 년 동안 업그레이드하지 않는데, 그 이유는 모든 변수 선언과 클래스가 멤버 및 함수 매개변수 및...는 ?로 주석 처리됩니다. null일 수 있는 경우. 2to3(Python 2 to 3 마이그레이션 도구)조차도 이와 같은 광범위한 변경을 처리할 필요가 없습니다.

2.0이 주요 변경 사항을 감당할 수 있는지 여부는 TS 팀에 따라 다릅니다. 나는 찬성표를 던질 것입니다. 그러나 수정이 필요한 백만 줄짜리 코드베이스가 없기 때문에 아마도 제 투표는 계산되지 않을 것입니다.

아마도 우리는 Funscript 사람들에게 F#과 null을 반환하는 DOM API를 조정하는 방법을 물어봐야 할 것입니다(Funscript는 F# 코드에서 사용하기 위해 TypeScript의 lib.d.ts 및 기타 .d.ts를 사용합니다). 나는 그것을 사용한 적이 없지만 예를 들어 http://funscript.info/samples/canvas/index.html 을 보면 유형 공급자가 document.getElementsByTagName("canvas")[0]이 될 수 있다고 생각하지 않는 것 같습니다. 찾으시는 주소가 없습니다.

편집: 여기 document.getElementById()가 null을 반환할 것으로 예상되지 않는 것 같습니다. 적어도 결과에서 .onlick에 액세스하는 것을 볼 때 Option<Element>를 반환하지 않는 것 같습니다.

@spion
고마워, 나는 그것에 대해 생각하지 않았다.

직장에서 우리의 코드베이스는 작지 않으며, 사람들이 원하는 이 획기적인 변화는 우리를 아주 적은 이득으로 많은 시간을 지연시킬 것입니다. 좋은 표준과 개발자 간의 명확한 의사 소통을 통해 null이 표시되어서는 안 되는 곳에 null이 표시되는 문제가 발생하지 않았습니다.
일부 사람들이 그렇게 심하게 밀고 있다는 사실에 솔직히 놀랐습니다.
말할 필요도 없이 이것은 우리에게 아주 적은 이익을 줄 것이고 우리에게 많은 시간을 요할 것입니다.

@Griffork 는 이 변경 사항이 얼마나 큰 이점을 가져올 수 있는지 추정하기 위해 typescript 컴파일러에서 필터링된 문제 목록을 살펴보았습니다. 해당 링크에 나열된 모든 "충돌" 버그는 nullable이 아닌 유형을 사용하여 피할 수 있습니다. 그리고 여기서 우리는 놀라운 Microsoft 수준의 표준, 통신 및 코드 검토에 대해 이야기하고 있습니다.

파손과 관련하여 기존 유형 정의를 계속 사용하면 컴파일러가 잠재적으로 초기화되지 않은 변수 및 누출되는 필드를 지적하는 것을 제외하고는 오류가 전혀 발생하지 않을 가능성이 있다고 생각합니다. 반면에, 특히 예를 들어 코드의 생성자에서 클래스 필드가 종종 초기화되지 않은 상태로 남아 있는 경우(나중에 초기화될) 많은 오류가 발생할 수 있습니다. 따라서 나는 당신의 우려를 이해하며 TS 1.x에 대한 이전 버전과 호환되지 않는 변경을 추진하지 않습니다. 나는 여전히 언어에 대한 변경 사항이 이전 버전과의 호환성을 깨뜨릴 가치가 있다면 이것이 바로 이것이라는 것을 설득할 수 있기를 바랍니다.

어쨌든 Facebook의 Flow 에는 nullable이 아닌 유형이 있습니다. 더 성숙해지면 이 문제에 관심이 있는 우리를 위해 TS를 대신하여 조사해 볼 가치가 있습니다.

@spion , 귀하의 목록이 우리에게 제공하는 유일한 숫자는 null 또는 undefined가 어떤 이유로 언급된 횟수입니다.

@aleksey-bykov 저는 아닙니다. 필터링된 목록의 _모든_ 문제를 살펴보았고 그 안에 "crash"라는 단어가 있는 모든 문제는 함수가 속성 또는 메서드에 액세스하려고 시도했음을 보여주는 스택 추적과 관련되었습니다. 정의되지 않았거나 null 값입니다.

나는 다른 키워드로 필터 범위를 좁히려고 노력했고 (나는) 모든 키워드

@spion
질문: 변수를 nullable 또는 undefinable로 표시해야 하는 위치에서 이러한 오류가 얼마나 많이 발생합니까?

EG 개체에 부모가 있을 수 있고 부모를 null로 초기화하고 항상 부모가 null인 하나의 개체를 갖게 되는 경우에도 부모를 null 가능성이 있는 것으로 선언해야 합니다.
여기서 문제는 프로그래머가 루프가 null 부모에 도달하기 전에 항상 중단된다는 가정 하에 일부 코드를 작성하는 경우입니다. 그것은 언어에 null이 있는 문제가 아니며, undefined 에서도 똑같은 일이 발생할 것입니다 .

null을 지금처럼 사용하기 쉽게 유지하는 이유:
• 정의되지 않은 것보다 더 나은 기본값입니다.
. 1) 어떤 경우에는 확인하는 것이 더 빠릅니다(우리 코드는 매우 성능이 좋아야 함)
. 2) for in 루프가 객체에서 더 예측 가능하게 작동합니다.
. 3) 빈 값(결측값과 반대)에 null을 사용할 때 배열 사용이 더 합리적입니다. delete array[i] 및 array[i] = undefined 는 indexOf(및 아마도 다른 인기 있는 배열 메서드)를 사용할 때 다른 동작을 가집니다.

null을 만든 결과 언어에서 사용하려면 추가 마크업이 필요하다고 생각합니다.
• null 오류 대신 정의되지 않은 오류가 발생했습니다(대부분의 typescript 시나리오에서 발생함).

내가 null 이스케이프에 문제가 없다고 말했을 때 null로 초기화되지 않은 변수는 null이 되지 않으며 정의되지 않은 오류가 발생하는 것과 정확히 같은 위치에서 여전히 null 예외 오류가 발생합니다(Typescript 팀도 마찬가지입니다). ). null을 사용하기 어렵게 만들고(추가 구문을 요구하여) 정의되지 않은 상태로 두는 것은 실제로 일부 개발자(예: 우리)에게 더 많은 문제를 일으킬 것입니다.

null을 사용하기 위해 추가 구문을 추가한다는 것은 null을 많이 사용하는 개발자가 새 구문을 기억하려고 하는 동안 왼쪽, 오른쪽 및 가운데 오류를 몇 주/달 동안 만들 수 있음을 의미합니다. 그리고 이것은 미래에 실수하는 또 다른 방법이 될 것입니다(뭔가 약간 잘못 주석을 다는 것). [유형을 나타내기 위해 기호를 사용하는 아이디어가 싫다는 점을 지적할 시간입니다. 언어가 덜 명확해집니다.]

null이 undefined가 아닌 오류나 문제를 일으키는 상황을 나에게 설명할 수 있을 때까지 나는 null을 undefined보다 사용하기 훨씬 더 어렵게 만드는 데 동의하지 않을 것입니다. 그것은 유스 케이스를 가지고 있으며, 그것이 당신에게 도움

결론:
정의되지 않은 유형을 정의할 수 없는 상태에서 nullable이 아닌 유형을 선언할 수 있다는 것은 의미가 없습니다. 그리고 자바스크립트가 작동하는 방식 때문에 정의되지 않은 유형은 불가능합니다.

@Griffork는 nullable이 아니라고 말할 때 nullable 또는 undefined를 의미합니다. 그리고 JS가 작동하는 방식 때문에 불가능하다는 것은 사실이 아닙니다. 새로운 유형 가드 기능을 사용하면 유형 가드를 사용하면 거기에서 흘러나오는 값이 더 이상 null이거나 정의되지 않음을 알 수 있습니다. 여기에도 트레이드오프가 있으며, 저는 Facebook Flow의 구현 을 충분히 할 수 있다는 증거로 제출합니다.

사용하기가 약간 더 어려워지는 _only_ 경우는 다음과 같습니다. 이 변수에 일시적으로 null을 할당한 다음 null이 아닌 것처럼 이 다른 메서드에서 사용할 것입니다. 변수를 먼저 초기화하므로 null을 확인할 필요가 없습니다. 이것은 매우 깨지기 쉬운 코드이며 컴파일러가 이에 대해 경고하는 것을 환영합니다. 어쨌든 버그가 아닌 리팩터링입니다.

@spion
나는 마침내 당신이 어디에서 왔는지 이해하고 있다고 믿습니다.

나는 당신이 값이 null이 될 수 없는 때를 결정하는 데 도움이 되는 유형 가드를 원하고 있다고 생각하며, 내부에서 null을 확인하지 않는 함수를 호출할 수 있도록 합니다. 그리고 보호하는 if-문이 제거되면 오류가 됩니다.

유용하다고 볼 수 있습니다.

나는 또한 이것이 실제로 당신이 바라는 은총알이 되지 않을 것이라고 믿습니다.

코드를 실행하지 않고 코드의 모든 측면을 테스트하지 않는 컴파일러는 코드를 작성한 프로그래머보다 undefined/null이 있는 위치를 결정하는 데 더 좋지 않을 것입니다. 이 변경으로 인해 사람들이 잘못된 보안 의식을 갖게 되고 실제로 null/정의되지 않은 오류가 발생했을 때 추적하기가 더 어려워질까 염려됩니다.
정말, 당신이 필요로 하는 솔루션은 약속을 이행할 수 없는 컴파일러에서 유형을 구현하는 것이 아니라 Javascript에서 이러한 종류의 버그를 재현할 수 있는 Typescript를 지원하는 좋은 테스트 도구 세트라고 생각합니다.

Flow가 이 문제에 대한 해결책을 가지고 있다고 언급했지만 귀하의 링크를 읽을 때 다음과 같은 몇 가지 관련 사항을 보았습니다.

"흐름은 때때로 개체 속성의 유형을 조정할 수도 있습니다. 특히 확인과 사용 사이에 중간 작업이 없을 때 그렇습니다. 그러나 일반적 으로 개체의 앨리어싱은 이러한 형태의 추론 범위를 제한합니다. 별칭을 통해 해당 속성에 대한 쓰기로 무효화되고 정적 분석이 별칭을 정확하게 추적하기 어렵습니다 ."

"null과 마찬가지로 정의되지 않은 값도 문제를 일으킬 수 있습니다. 불행히도 정의되지 않은 값은 JavaScript에서 어디에나 있으며 언어의 유용성에 심각한 영향을 미치지 않고는 피하기 어렵습니다[...] Flow는 이 경우 절충점을 만듭니다. 정의되지 않은 지역 변수를 감지하고 값을 반환하지만 개체 속성 및 배열 요소 액세스로 인해 정의되지 않을 가능성은 무시합니다 ."

이제 정의되지 않은 것과 null이 다르게 작동합니다. 정의되지 않은 오류는 여전히 어디에나 나타날 수 있으며 물음표는 값이 null이 아니라고 보장할 수 없으며 언어는 Javascript와 더 다르게 동작합니다(TS가 내가 본 것에서 피하려고 하는 것입니다) ).

추신

foo(thing: whatiknowaboutmyobject) {
    if (thing.hidden) {
        delete thing.description;
    }
}

if (typeof thing.description === "string") {
    //thing.description is non-nullable now, right?
    foo(thing);
    //What is thing.description?
    console.log(thing.description.length);
}

TS는 이미 앨리어싱 효과에 취약합니다(변경 가능한 값을 허용하는 모든 언어와 마찬가지로). 이것은 오류 없이 컴파일됩니다:

function foo(obj: { bar: string|number }) {
    obj.bar = 5;
}

var baz: { bar: string } = { bar: "5" };

foo(baz);

console.log(baz.bar.charAt(0)); // Runtime error - Number doesn't have a charAt method

Flow 문서는 완전성을 위해서만 이것을 명시하고 있습니다.

편집: 더 나은 예.

낡은:

예, 하지만 정의되지 않은 것을 설정하는 수단이 무언가를 다른 값으로 설정하는 수단보다 훨씬 더 크다고 저는 주장합니다.

내 말은,

mything.mystring = 5; // is clearly wrong.
delete mything.mystring; //is not clearly wrong - this is not quite the equivalent of setting mystring to >undefined.

편집하다:
음, 이 시점에서는 지극히 개인적인 취향입니다. 오랫동안 자바스크립트를 사용한 후에는 이 제안이 언어에 도움이 되지 않을 것이라고 생각합니다. 나는 그것이 사람들을 잘못된 보안 의식으로 유인할 것이라고 생각하고 Typescript(언어로서의)를 Javascript에서 멀어지게 할 것이라고 생각합니다.

@Griffork 현재 타이프스크립트가 어떻게 당신을 잘못된 보안 감각에 빠지게 하는지에 대한 예를 보려면 놀이터에서 제시한 예를 시도하십시오.

var mything = {mystring: "5"}; 
delete mything.mystring;
console.log(mything.mystring.charAt(1));

그건 그렇고, 삭제 연산자는 null 유형의 값을 할당하는 것과 같은 방식으로 처리될 수 있으며 이 경우에도 충분합니다.

언어가 JavaScript와 다르게 동작할 것이라는 주장은 사실이지만 의미가 없습니다. TypeScript에는 이미 JavaScript와 다른 동작이 있습니다. 유형 시스템의 요점은 항상 말이 안 되는 프로그램을 허용하지 않는 것입니다. nullable이 아닌 유형을 모델링하면 몇 가지 추가 제한 사항이 추가됩니다. null을 허용하지 않는 유형의 변수에 null 또는 정의되지 않은 값을 할당하는 것을 허용하지 않는 것은 문자열 유형의 변수에 숫자를 할당하는 것을 허용하지 않는 것과 정확히 동일합니다. JS는 둘 다 허용하지만 TS는 둘 다 허용하지 않습니다.

@spion

아이디어는 코드의 모든 곳에서 null 검사를 피하는 것입니다.

귀하가 옹호하는 내용을 이해한다면:

A. 기본적으로 모든 유형을 null이 아닌 것으로 만듭니다.
B. nullable인 필드와 변수를 표시합니다.
C. 응용 프로그램/라이브러리 개발자가 응용 프로그램에 대한 모든 진입점을 확인하는지 확인합니다.

그러나 그것은 자신의 코드에 null이 없는지 확인하는 책임은 컴파일러가 아니라 코드를 작성하는 사람에게 있음을 의미하지 않습니까? 우리는 컴파일러에게 효과적으로 "dw, 나는 시스템에 어떤 null도 허용하지 않을 것입니다."라고 말하고 있습니다.

대안은 null이 어디에나 있으므로 신경쓰지 말고 null을 허용할 수 없는 항목이 있으면 알려 드리겠습니다.

사실 후자의 접근 방식은 null 참조 예외가 발생하기 쉽지만 더 사실적입니다. 와이어(예: ajax)를 통해 얻은 객체의 필드가 null이 아닌 척하는 것은 God :smiley: 에 대한 믿음이 있음을 의미합니다.

작업 중인 항목에 따라 위의 C 항목이 사소하거나 실행 불가능할 수 있기 때문에 이 문제에 대해 큰 이견이 있다고 생각합니다.

@jbondc 물어봐 주셔서 기쁩니다. 실제로 CallExpression은 정의되지 않음 또는 nullable로 표시됩니다. 그러나 유형 시스템은 현재 이를 활용하지 않습니다. typeArguments 에 대한 모든 작업이 null이 아니거나 정의되지 않은 것처럼 여전히 허용됩니다.

그러나 nullable이 아닌 유형과 함께 새로운 공용체 유형을 사용할 때 유형을 NodeArray<TypeNode>|null 로 표현할 수 있습니다. 그러면 유형 시스템은 null 검사가 적용되지 않는 한 해당 필드에 대한 작업을 허용하지 않습니다.

if (ce.typeArguments != null) {
  callSomethingOn(ce.typeArguments)
}

// callSomethingOn doesn't need to perform any checks

function callSomethingOn(na:NodeArray<TypeNode>) {
...
}

TS 1.4 유형 가드의 도움으로 if 블록 내에서 표현식의 유형이 NodeArray<TypeNode> 로 좁혀지며 해당 유형에 대한 모든 NodeArray 작업이 허용됩니다. 또한 해당 검사 내에서 호출된 모든 함수는 더 이상 검사를 수행하지 않고도 인수 유형을 NodeArray<TypeNode> 로 지정할 수 있습니다.

하지만 쓰려고 하면

function someOtherFunction(ce: CallExpression) {
  callSomethingOn(ce.typeArguments)
}

컴파일러는 컴파일 타임에 이에 대해 경고하고 버그는 발생하지 않았을 것입니다.

아니요, @NoelAbrahams , 이것은 모든 것을 확실히 아는 것이 아닙니다. 다른 모든 유형과 마찬가지로 변수 또는 필드에 포함될 수 있는 값을 알려주는 컴파일러에 관한 것입니다.

물론 외부 값의 경우 항상 그렇듯이 유형을 지정하는 것은 사용자의 몫입니다. 외부 데이터에는 숫자 대신 문자열이 포함되어 있으며 컴파일러는 불평하지 않지만 숫자에 대해 문자열 작업을 수행하려고 할 때 프로그램이 충돌한다고 항상 말할 수 있습니다.

그러나 nullable이 아닌 유형이 없으면 값이 null일 수 없다고 말할 수 있는 능력조차 없습니다. null 값은 모든 유형에 할당할 수 있으며 이에 대해 제한을 둘 수 없습니다. 변수는 초기화되지 않은 상태로 둘 수 있으며 undefined 는 모든 유형에 유효한 값이므로 경고를 받지 않습니다. 따라서 컴파일러는 컴파일 시간에 null 및 정의되지 않은 관련 오류를 잡는 데 도움을 줄 수 없습니다.

nullable이 아닌 유형에 대해 그렇게 많은 오해가 있다는 것이 놀랍습니다. 초기화되지 않은 상태로 둘 수 없거나 null 또는 undefined 값을 할당할 수 없는 유형입니다. 이것은 숫자에 문자열을 할당할 수 없는 것과 다르지 않습니다. 이것은 내가 정말로 아무데도 가고 있지 않다고 느끼기 때문에이 문제에 대한 나의 마지막 게시물입니다. 더 자세히 알고 싶은 사람이 있다면 위에서 언급한 "십억 달러의 실수" 동영상부터 시작하는 것이 좋습니다. 이 문제는 잘 알려져 있으며 많은 현대 언어와 컴파일러에서 성공적으로 해결되었습니다.

@spion , 유형이 null일 수 있는지 여부를 명시할 수 있는 모든 이점에 대해 전적으로 동의합니다. 그러나 질문은 유형이 _ 기본적으로 _ null이

와이어(예: ajax)를 통해 얻은 객체의 필드가 null이 아닌 척하는 것은 신에 대한 믿음이 있음을 의미합니다.

그러니 척 하지마. nullable로 표시하면 nullable이 아닌 것으로 사용하기 전에 테스트해야 합니다.

확신하는. 필드를 nullable로 표시할지(필드가 기본적으로 null이 아닌 시스템에서) 또는 필드를 non-nullable로 표시할지(필드가 기본적으로 nullable인 시스템에서)로 요약됩니다.

주장은 전자가 주요 변경 사항(중요하거나 중요하지 않을 수 있음)이며 응용 프로그램 개발자가 모든 진입점을 확인하고 보장해야 하기 때문에 유지될 수 없다는 것입니다.

@NoelAbrahams 기본적으로 null을 원하지 않는 경우가 대부분이며 진입점이 null 을 반환할 수 있는 경우에도 확인해야 하는 이유를 알 수 없습니다. 결국 null이 아닌 유형의 유형 시스템 기본적으로 애플리케이션의 일부 API/라이브러리/진입점을 신뢰할 수 있기 때문에 null 검사를 덜 수행할 수 있습니다.

nullable 형식 시스템에서 형식을 null이 아닌 것으로 표시하는 것에 대해 조금 생각해보면 값이 제한되어 있으므로 강제로 테스트하지 않고도 nullable 형식 변수/반환 형식을 사용할 수 있습니다.
또한 대부분의 경우 잘 설계된 라이브러리는 null이나 정의되지 않은 값을 반환하지 않기 때문에 정의 작성자는 더 많은 코드를 작성해야 합니다.
마지막으로 개념조차 이상합니다. nullable 형식이 아닌 형식 시스템에서 nullable 형식은 공용체 형식으로 완벽하게 표현할 수 있습니다. ?string 는 string | null | undefined . nullable 형식을 기본값으로 사용하는 형식 시스템에서 형식을 nullable이 아닌 것으로 표시할 수 있는 경우 !string 어떻게 표현할까요? string - null - undefined ?

결국 나는 여기 사람들의 우려를 정말로 이해하지 못합니다. null 는 문자열이 아닙니다. 5 가 문자열이 아닌 것과 같은 방식으로 두 값 모두 다음을 수행할 수 없습니다. 문자열이 예상되는 경우 사용하고,시키는 슬립 수 var myString: string = null 같은 경향이 오류로이다 : var myString: string = 5 .
모든 유형에 null 또는 undefined를 할당할 수 있다는 것은 개발자에게 친숙한 개념일 수 있지만 여전히 나쁜 개념입니다.

내 이전 게시물에서 내가 완전히 옳았다고 생각하지 않습니다. 시간에 그것을 비난할 것입니다.

작동 방식을 확인하기 위해 일부 코드를 살펴보았으며 다음과 같이 특정 필드를 nullable로 표시하는 데 확실히 도움이 될 것입니다.

interface Foo {
        name: string;
        address: string|null; /* Nullable */
}

var foo:Foo = new FooClass();
foo.name.toString(); // Okay
foo.address.toString(); // Error: do not use without null check

그러나 내가 반대하는 것은 다음과 같습니다.

foo.name = undefined; // Error: non-nullable

나는 이것이 자바스크립트를 사용하는 자연스러운 방식을 방해할 것이라고 생각합니다.

number 에도 정확히 동일하게 적용될 수 있습니다.

interface Foo {
        name: string;
        address: string|number; 
}
var foo:Foo = new FooClass();
foo.name.toString(); // Okay
foo.address.slice() // error

foo.name  = 5 // error

그리고 여전히 JavaScript에서 유효합니다.

합리적으로 몇 번이나 객체의 속성에 기꺼이 null을 할당합니까?

대부분의 항목이 null로 표시되지만 필드가 이제 nullable이 아님을 선언하는 형식 가드에 의존할 것이라고 생각합니다.

@fdecampredon
꽤 많습니다.

@그리포크

나는 대부분의 것들이 null로 표시될 것이라고 생각한다

그것이 나의 초기 생각이었다. 그러나 코드의 일부 섹션을 살펴본 후 다음과 같은 주석을 발견했습니다.

interface MyType {

     name: string;

     /** The date the entry was updated from Wikipedia or undefined for user-submitted content. */
     wikiDate: Date; /* Nullable */
}

필드가 nullable이라는 아이디어는 종종 정보를 제공하는 데 사용됩니다. 그리고 TypeScript는 wikiDate 액세스할 때 유형 가드가 필요한 경우 오류를 포착합니다.

@fdecampredon

foo.name = 5 // error
그리고 여전히 JavaScript에서 유효합니다.

사실이지만 TypeScript는 의도적인 것이 아님을 100% 확신하기 때문에 오류입니다.

반면

foo.name = 정의되지 않음; // 서버에 이름을 보내지 않음

완전히 의도적입니다.

우리의 요구 사항에 가장 잘 맞는 구현은 공용체 유형을 사용하지 않고 원래 제안을 따르는 것이라고 생각합니다.

 wikiDate: ?Date;

@NoelAbrahams에 동의합니다.

foo.name = 5 // 오류
그리고 여전히 JavaScript에서 유효합니다.
사실이지만 TypeScript는 의도적인 것이 아님을 100% 확신하기 때문에 오류입니다.

컴파일러는 이름을 string 하고 string | number 가 아닌 null 허용 값을 원할 경우 ?string 또는 string | null ( 거의 동등합니다)

우리의 요구 사항에 가장 잘 맞는 구현은 공용체 유형을 사용하지 않고 원래 제안을 따르는 것이라고 생각합니다.

위키날짜: ?날짜;

따라서 우리는 기본적으로 유형이 null이 아니라는 데 동의하고 ? :)로 nullable을 표시할 것입니다.
?Date 는 Date | null | undefined 와 동일하므로 공용체 유형이 됩니다. :)

아 죄송합니다. 기본적으로 nullable에 동의하고 특수 입력에서는 null이 아닌 것에 동의하려고 했습니다(기호가 혼동됨).

@fdecampredon , 실제로 의미하는 바는 필드 또는 변수가 nullable로 표시되면 액세스를 위해 유형 가드가 필요하다는 것입니다.

var wikiDate: ?Date;

wikiDate.toString(); // error
wikiDate && wikiDate.toString(); // okay

이것은 우리가 여전히 이것을 할 수 있어야 하기 때문에 브레이킹 체인지가 아닙니다:

 var name: string;   // okay
 name.toString();  // if you think that's fine then by all means

아마도 null 를 공용체 유형에 도입하지 않고는 이것을 가질 수 없다고 생각하십니까?

다음을 수행할 때 첫 번째 예가 절대적으로 옳습니다.

wikiDate && wikiDate.toString(); // okay

당신은 typeguard를 사용하고 컴파일러는 아무 것도 경고해서는 안됩니다.

그러나 두 번째 예는 좋지 않습니다.

var name: string;   // okay
name.toString();  // if you think that's fine then by all means

컴파일러는 여기에 오류가 있어야 합니다. 간단한 알고리즘은 첫 번째 줄에서 오류가 발생할 수 있습니다(nullable로 표시되지 않은 단위화된 변수). 더 복잡한 알고리즘은 처음 사용하기 전에 할당을 감지하려고 시도할 수 있습니다.

var name: string;   // okay
name.toString();  // error because not initialized

var name: string;
if (something) {
  name = "Hello World";
} else {
  name = "Foo bar";
}
name.toString();  // no error since name will always be initialized.

장벽을 어디에 둘지 정확히 모르지만 개발자를 방해하지 않으려면 일종의 미묘한 조정이 필요합니다.

@metaweta에서 제안한 'null이 아닌 사용' 지시문을 제외하고는 브레이킹 체인지이며 2.0 이전에는 도입할 수 없습니다.

왜 없는지:

var string1: string; //this works like typescript does currently, doesn't need type-guarding before use, null and undefined can be assigned to it.
string1.length; //works
var string2: !string; //this doesn't work because the string must be assigned to a non-null and non-undefined value, doesn't need type-guarding before use.
var string3: ?string; //this must be type guarded to non-null, non-undefined before use.
var string4: !string|null = null; //This may be null, but should never be undefined (and must be type-guarded before use).
var string5: !string|undefined; //this may never be null, but can be undefined (and must be type-guarded before use).

그리고 -noinferrednulls라고 하는 컴파일러 플래그(-noimplicitany가 켜져 있는 경우에만 작동)가 있어 유형(예: string 및 int)에 대한 일반 구문을 비활성화하고 ? 또는 ! (null, undefined 및 모든 유형은 예외).

이러한 방식으로 nullable이 아닌 항목은 옵트인이며 컴파일러 플래그를 사용하여 프로젝트를 명시적으로 null로 만들 수 있습니다.
(이전 제안과 같이) 이후가 아니라 유형 할당 시 컴파일러 플래그 오류입니다.

생각?

편집: 모든 작업에서 null이 아닌 것을 명시적으로 사용해야 하기 때문에 이것을 썼습니다. 다른 TS 프로젝트에서 가져온 코드를 읽는 사람이라면 무슨 일이 일어나고 있는지 정확히 알 것입니다. 또한 컴파일러 플래그가 켜져 있으면 매우 분명해집니다( blah: string 는 오류이지만 blah:!string 는 오류가 아니므로 -noimplicitany 작동 방식과 유사함).

편집2:
그런 다음 DefinatelyTyped는 noninferrednull을 지원하도록 업그레이드할 수 있으며 사람들이 ? 그리고 ! 특징.

null이 아닌 것과 정의되지 않은 것이 옵트인, 옵트아웃인지 여부는 상관하지 않습니다.
유형 수정자(!?), 지시문 또는 컴파일러 플래그 난 뭐든지 할거야
그들이 _표현할 수 있는 한_ 그것들을 얻는 데 시간이 걸립니다.
현재 사례.

2014년 12월 22일 월요일 오후 2시 35분에 Griffork [email protected]에서 다음과 같이 썼습니다.

왜 없는지:

var string1: 문자열; // 이것은 현재 typescript가 하는 것처럼 작동합니다. 사용하기 전에 유형 보호가 필요하지 않으며 null 및 undefined를 할당할 수 있습니다.
문자열1.길이; //worksvar string2: !string; // 문자열이 null이 아닌 정의되지 않은 값에 할당되어야 하기 때문에 작동하지 않습니다. use.var string3: ?string; //이것은 use.var string4: !string|null = null; // null일 수 있지만 정의되지 않은 상태여서는 안 됩니다(사용하기 전에 유형 보호되어야 함).var string5: !string|undefined; // 이것은 null이 될 수 없지만 정의되지 않을 수 있습니다(사용하기 전에 유형 보호되어야 함).

그리고 컴파일러 플래그가 있습니다(-noimplicitany가 켜져 있는 경우에만 작동함).
유형에 대한 일반 구문을 비활성화하는 -noinferrednulls라고 말합니다(예:
string 및 int)를 제공해야 하고 ? 또는 ! 그들과 함께(null, undefined
및 예외).

이러한 방식으로 non-nullable은 옵트인이며 컴파일러를 사용할 수 있습니다.
프로젝트를 강제로 null로 지정하는 플래그입니다.
컴파일러 플래그 오류는 _유형 지정_ 이후가 아니라(예:
이전 제안).

생각?

이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/Microsoft/TypeScript/issues/185#issuecomment -67899445
.

마이크 스테이 - [email protected]
http://www.cs.auckland.ac.nz/~mike
http://reperiendi.wordpress.com

@Griffork 는 옵션이 될 수 있지만 제 생각에는 나쁜 옵션이며 그 이유를 설명하겠습니다.

• 정의 파일에서 훨씬 더 많은 작업을 수행하게 될 것입니다. 이제 모든 유형에 올바른 정의가 있는지 확인하고 주석을 달아야 하기 때문입니다.
• 우리는 코드의 모든 곳에 !string (때로는 ?string )를 작성하여 코드 가독성을 훨씬 떨어뜨릴 것입니다.
• 유형이 nullable인 시스템에서 !string 는 이상한 개념입니다. 실제로 설명할 수 없는 유일한 방법은 string minus null minus undefined 입니다. 반대로 ?string 는 설명하기 매우 간단합니다. 유형이 기본적으로 null인 유형 시스템 string | null | undefined .
• 컴파일러가 string | null 에 유형 가드가 필요하지만 string 에는 필요하지 않다는 것을 컴파일러가 이해하는 유형 검사 알고리즘을 찾는 데 많은 골칫거리(및 성능 손실)가 있을 것으로 예상합니다. 기본적으로 다음과 같은 개념을 도입합니다. 일부 공용체 유형은 다른 유형과 다르게 취급되어야 합니다.
• 그리고 마지막으로 최악의 부분은 var myString = "hello" myString이 string , ?string 또는 !string 여야 하는 var myString = "hello" 을 완전히 느슨하게 하는 부분입니다. 솔직히 여기서 관점에서 보면 큰 골칫거리입니다.

기본값으로 null이 아닌 유형이 없는 경우 여기에서 본 최고의 제안은 @metaweta가 제안한 'use non-null' 지시문입니다.
물론 잘 지정해야 하지만 모든 파일에 use non-null 문자열

@fdecampredon

1. 정의 파일에서 훨씬 더 많은 작업이 필요할 수 있지만 _어쨌든 그 작업을 수행해야 합니다_(유형이 올바른지 확인하기 위해) 그리고 이번에는 컴파일러가 아직 편집하지 않은 것을 알려줄 것입니다(-noimplicitnull을 사용하는 경우 ).
2. 나는 주석에 대한 다른 제안에 열려 있습니다. 저는 솔직히 현재 유형 시스템이 제자리를 갖고 있으며 _대체_되어서는 안 된다고 믿습니다. 나는 획기적인 변화가 가치가 있다고 생각하지 않습니다. 대신에 우리는 당신이 추구하는 바를 더 잘 설명할 수 있는 방법을 찾아야 한다고 생각합니다. (나는 이것을 기호로 표현하는 아이디어를 정말 정말 싫어합니다. 직관적이지 않습니다.)
3. 그것에 대해 설명하기 어려운 것은 무엇입니까? 이 요청(특정 유형에 대한)이 제안된(마커 없이) typescript의 다른 곳에서 토론을 보았습니다. 빠른 검색을 수행했지만 문제를 찾을 수 없었습니다. 나중에 더 찾아보겠습니다.
4. 
   내가 !string|null 로 작성한 것을 참조하는 경우 null이 _like_ {}(하지만 할당할 수 없음) 처리된 경우 현재 시스템에서 작동합니다.
   내 목록에 없는 string|null 에 대해 이야기하고 있다면 이 경우 null을 무시해야 한다고 생각합니다. Null 및 undefined는 모든 non-null 및 non-undefined 앞에 ! 그리고 any는 any가 아닙니다(컴파일러 경고/오류일 수 있음).
5. 좋은 질문이고 -noimplicitnull 옵션을 사용하는 경우에만 발생하는 질문입니다. 가장 안전한 옵션은 초기 오류(아마도 null 허용)를 유발할 가능성이 가장 높은 옵션에 할당하는 것입니다. 내가 생각하지 못한 더 나은 아이디어가 있다는 느낌. 다른 사람이 이것이 어떻게 접근해야 하는지에 대한 제안이 있는지 궁금합니다.

편집: 2번 항목에 추가되었습니다.
편집: 4번 항목의 오타를 수정했습니다.

정의 파일에서 훨씬 더 많은 작업이 필요할 수 있지만 어쨌든 그 작업을 수행해야 합니다(유형이 올바른지 확인하기 위해). 이번에는 컴파일러가 아직 편집하지 않은 것을 알려줄 것입니다(-noimplicitnull을 사용하는 경우 ).

예 및 아니오, 사용하는 라이브러리를 확인하고 실제로 얼마나 많이 null 또는 undefined를 반환하는지 확인하십시오.
아주 드문 경우입니다. 우리는 이 문제에서 표준 lib에 대해 거의 발생하지 않는다는 것을 발견할 수 있었습니다. 예를 들어 Promise 라이브러리는 절대 하지 않습니다.
내 요점은 기본적으로 유형이 null을 허용하지 않는 유형 시스템에서 대부분의 기존 정의 파일이 이미 유효하다는 것 입니다.

나는 주석에 대한 다른 제안에 열려 있습니다. 솔직히 현재 유형 시스템에는 제자리가 있으며 교체되어서는 안 된다고 생각합니다. 나는 획기적인 변화가 가치가 있다고 생각하지 않습니다. 대신에 우리는 당신이 추구하는 바를 더 잘 설명할 수 있는 방법을 찾아야 한다고 생각합니다. (나는 이것을 기호로 표현하는 아이디어를 정말 정말 싫어합니다. 직관적이지 않습니다.)

나는 그런 방법이 없다고 생각하지만 그것이 내 생각에 측량할 수 없는 가치를 가지고 있기 때문에 내가 틀렸기를 바랍니다.
주요 변경 부분의 경우 'use non-null' 지시문에 반대하는 이유는 무엇입니까?
null 허용 타입 시스템을 원하는 개발자들은 (아직 이상하게도 추가하지 않는 한 전혀 영향을받지 것 'use non-null' 자신의 파일의 상단에 있지만 솔직히 조금 ... 이상한 것)
그리고 null이 아닌 유형 시스템을 원하는 개발자는 새 지시문을 사용할 수 있습니다.

그것에 대해 설명하기 어려운 것은 무엇입니까? 이 요청(특정 유형에 대한)이 제안된(마커 없이) typescript의 다른 곳에서 토론을 보았습니다. 빠른 검색을 수행했지만 문제를 찾을 수 없었습니다. 나중에 더 찾아보겠습니다.
나는 개념이 약간 '이상하고' 명확하지 않다고 생각합니다. 저는 일반적으로 _decomposition_이 아니라 프로그래밍을 위한 주요 도구로 구성을 사용하지만 왜 그렇지 않은지 알 수 있습니다.

내가 !string|null로 작성한 것을 참조하는 경우 null이 {}처럼 처리되면 현재 시스템에서 작동합니다(하지만 할당할 수 없음). 내 목록에 없는 string|null에 대해 이야기하고 있다면 이 경우 null을 무시해야 한다고 생각합니다. Null 및 undefined는 모든 non-null 및 non-undefined 앞에 ! 그리고 any는 any가 아닙니다(컴파일러 경고/오류일 수 있음).
나는 당신이 3 가지 유형을 분해 할 때 다음과 같은 사실을 언급하고 있습니다.

• !sting : string - null - undefined
• string : string | null | undefined
• ?string : string | null | undefined

최신 2개는 기본적으로 차이가 없지만 컴파일러는 string 경우 type-guard 검사를 강제하지 않아야 하고 ?string 경우 해당 정보가 모든 곳에서 전파되어야 함을 알아야 합니다. 알고리즘은 실제보다 훨씬 더 복잡할 것이며 유형 추론에서 이상한 경우를 찾을 수 있다고 확신합니다.

좋은 질문이고 -noimplicitnull 옵션을 사용하는 경우에만 발생하는 질문입니다. 가장 안전한 옵션은 초기 오류(아마도 null 허용)를 유발할 가능성이 가장 높은 옵션에 할당하는 것입니다. 내가 생각하지 못한 더 나은 아이디어가 있다는 느낌. 다른 사람이 이것이 어떻게 접근해야 하는지에 대한 제안이 있는지 궁금합니다.

기본적으로 null에서 기본값으로 null로 전환할 수 있는 플래그를 도입하는 것에 대해 생각할 때 @RyanCavanaugh가 언급한 것과 동일한 문제를 기본적으로 도입하지 않을 것입니다.
이 경우 전자의 제안이 훨씬 더 간단했습니다.

또 왜 'use non-null' 지시에 반대하는 겁니까, 생각할수록 이상적인 솔루션인 것 같습니다.

@fdecampredon
현재 제안된 "null이 아닌 사용"은 언어가 _작성된_ 방식이 아닌 _사용되는_ 방식을 변경하기 때문입니다. 한 위치에서 다른 위치로 이동할 때 함수가 _사용_했을 때 다르게 작동할 수 있음을 의미합니다. 뭔가 잘못 입력했기 때문에 잠재적으로 1-3개 파일에 있는 컴파일 시간 오류가 발생합니다.

차이점:
string
그리고
?string
그게 ? 그리고 ! 기호는 이 변수에 대한 엄격한 유형 검사를 요구합니다("null이 아닌 사용" 지시문과 유사하지만 변수별로). 그런 식으로 설명하면 사람들이 그것을 이해하는 데 큰 어려움이 없을 것이라고 생각합니다.

물론 차이점은 다음과 같습니다.
파일 1:

//...187 lines of code down...
string myfoo(checker: boolean) {
    if(checker){
        return null;
    }
    else {
        return "hello";
    }
}

파일 2:

"use nonnull"
//...2,748 lines of code down...
string myfoo(checker: boolean) {
    if(checker){
        return null; //Error!
    }
    else {
        return "hello";
    }
}

이제 개발자는 null이 아닌 파일과 null이 아닌 파일에 대한 멘탈 맵을 유지해야 합니다. 나는 솔직히 이것이 나쁜 생각이라고 믿습니다(대부분의 _your_ 코드가 'null이 아닌 사용'일지라도).

편집: 또한 함수를 입력하기 시작하고 함수 정의가 무엇인지 알려주는 작은 창이 표시되면 해당 정의의 string 가 nullable인지 아니면 nonnullable인지 어떻게 알 수 있습니까?

@그리포크

• 'use strict' 의 경우에도 마찬가지입니다.
• 적어도 아이디어는 간단합니다. 유형 시스템에 간단한 개념을 도입합니다.
• 개발자가 다른 파일의 함수를 이동하면 나에게는 매우 극단적인 경우처럼 보이고 오류가 발생하면 null 검사에 대한 메시지가 표시되므로 무슨 일이 일어나는지 빠르게 이해할 수 있을 것입니다...

다시 말하지만 완벽하지는 않지만 더 나은 대안이 보이지 않습니다.

분명히 하자면, 내가 볼 수 있는 (반론 이후) 내가 제안한 것에 대한 귀하의 유일한 문제는 다음과 같습니다.

• var mystring = "string" 대한 동작이 무엇인지 알 수 없습니다.
• 모든 곳에 기호를 입력할 필요가 없습니다.

그리고 지침에 대한 나의 우려는 다음과 같습니다.

• null이 아닌 것은 명시적이지 않습니다(그러나 nullable과 동일한 프로젝트에서 발생할 수 있음). 편집 : 더 이해하기 쉽게 고정된 문구.
• 개발자는 작성 중인 내용이 nullable인지 여부를 추적하기가 더 어려울 것입니다.
• 함수를 호출할 때 표시되는 함수 정의( edit : 함수 입력을 시작할 때 Visual Studio에서 제공하는 팝업)는 nullable일 수도 있고 아닐 수도 있으며 말할 수 없을 수도 있습니다.
• 함수가 2개 또는 3개의 계층을 통해 래핑되면 해당 정의가 여전히 올바른지 알 수 없습니다("null이 아닌 사용"이 없는 파일을 통해 유형 추론을 사용할 수 없기 때문에).

솔직히 "use strict"의 구현은 열망해야 하는 것이
그리고 나는 왜 지시문이 개발자들에게 그들의 의도를 명시하도록 강요하는 것보다 더 나은지 알 수 없습니다.

편집: 요점을 명확히 했습니다.
편집: 문자열을 따옴표로 묶습니다.

솔직히 말해서 내 관심사에 대한 귀하의 요약은 약간 작고 제가 작성한 내용을 반영하지 않습니다. 귀하의 제안은 유형 시스템에 복잡성을 더하고 유형 검사 알고리즘을 골치 아프게 만들며 모든 극단적 인 경우로 지정하기가 꽤 어렵습니다. 유형 추론을 위해 특별히 만들고 코드를 매우 장황하게 만듭니다. 기본적으로 작업에 적합한 도구가 아닙니다.

null이 아닌 모든 항목을 명시적으로 지정하고 싶습니다(nullable과 동일한 프로젝트에서 발생할 수 있기 때문에).

string 가 실제로 string | null | undefined 라는 사실을 명시적으로 확인하도록 강요하지 않고 싶습니다.

개발자는 작성 중인 내용이 nullable인지 여부를 추적하기가 더 어려울 것입니다.

프로젝트에서 null이 아닌 값을 사용하고 파일 상단에서 스크롤하는 것이 그렇게 어렵지 않은 경우 'null이 아닌 사용'이 없는 프로젝트에 단일 파일이 있을지 의심됩니다(적어도 500줄 미만의 코드로 파일을 작성할 때 대부분의 경우입니다 ...)

함수를 호출할 때 표시되는 함수 정의는 nullable일 수도 있고 그렇지 않을 수도 있으며 말할 수 없습니다.

예, 'null이 아닌 사용' 지시문이 있는 모듈에서 가져온 경우 모든 것을 nullable로 간주하지 않으면 그에 따라 입력됩니다...

함수가 2개 또는 3개의 계층을 통해 래핑되면 해당 정의가 여전히 올바른지 알 수 없습니다("null이 아닌 사용"이 없는 파일을 통해 유형 추론을 사용할 수 없기 때문에).

나는 여기서 당신의 요점을 이해하지 못합니다.

솔직히 "use strict"의 구현은 열망해야 하는 것이 아닙니다. JavaScript(Typescript가 아님)용으로 설계되었으며 JavaScript에는 귀중한 대안이 거의 없습니다. 우리는 Typescript를 사용하고 있으므로 일을 더 잘할 수 있는 옵션이 있습니다.
그리고 나는 왜 지시문이 개발자들에게 그들의 의도를 명시하도록 강요하는 것보다 더 나은지 알 수 없습니다.

TypeScript는 JavaScript의 상위 집합이며 JavaScript에 뿌리를 두고 있으며 목표는 JavaScript를 더 안전한 방법으로 작성할 수 있도록 하는 것이므로 JavaScript 개념을 재사용하는 것이 비합리적으로 보이지 않습니다.

그리고 나는 왜 지시문이 개발자들에게 그들의 의도를 명시하도록 강요하는 것보다 더 나은지 알 수 없습니다.

동일한 결과를 얻을 수 없기 때문에 nullable 형식 시스템에서 nullable이 아닌 형식을 사용하는 것은 단지 나쁜 생각일 뿐입니다.

내 관점에서 여기에는 3가지 실행 가능한 솔루션이 있습니다.

• 유형이 null을 허용하지 않는 2.0의 주요 변경 사항
• 내가 수십 개의 주석을 제안한 것처럼 기본적으로 nullable이 아닌 유형으로 전환하는 컴파일러 플래그이지만 @RyanCavanaugh 는 이에 대해 좋은 지적을 했습니다. (솔직히 그만한 가치가 있다고 생각하는 경우)
• 'null이 아닌 사용' 지시문

그건 그렇고, 깃발은 나에게 완전히 가치가 있습니다.

function fn(x: string): number;
function fn(x: number|null): string;

function foo() {
    return fn(null);
}

var x = foo(); // x: number or x: string?

함수가 유일한 관심사인 경우 오버로드에 명시적 null 인수가 포함된 경우 예외가 발생할 수 있습니다. 이는 항상 암시적 null보다 우선합니다( --noImplicitNull 와 조화를 이루기 위해). . 이것은 또한 사용자에게 의미가 있는 해석이 될 것입니다(즉, "명시적으로 말한 내용은 암시적으로 말한 내용보다 우선해야 함"). 이 방법으로 해결할 수없는 플래그에 다른 유사한 문제가 있는지 궁금합니다. 물론 이것은 사양과 구현 모두에 약간의 해킹 복잡성을 추가합니다.

1. string|null|undefined 플래그를 사용하는 내 제안에 명시적이므로 생략했습니다.
2. 그렇다면 왜 파일 당 가지고 있습니까? 제 제안을 제안하는 것은 저와 다른 많은 개발자에게 중요한 _하위 호환성을 깨뜨리지 않기 때문입니다. 그리고 프로젝트 전체에 강제로 적용 할 수 있습니다.
3. 내가 만들지 않은 파일을 많이 사용합니다. 특정 파일에 "null이 아닌 사용"이 있다는 것을 어떻게 알 수 있습니까? 다른 사람이 만든 100개의 파일이 있는 경우 그 100개의 파일 중 null이 아닌 파일을 외워야 합니까? (또는, _매번_ 다른 파일의 변수/함수를 사용할 때 해당 파일을 열어 확인해야 합니까?)
4. 내가 이것을 더 명확하게 할 수 있는지 봅시다. 게시물 끝에 있는 예시입니다.
5. 어디에서 멈추나요? 어디가 나쁘다고 합니까? 파일 시작 부분에 있는 하나의 문자열 또는 키워드는 파일 동작 방식을 변경해서는 안 됩니다. "use strict"가 자바스크립트에 추가되었습니다.
   
   
   
   1. 원하는 것을 수행할 수 있는 Javascript(예: Typescript)의 대규모 수퍼 세트가 당시에는 존재하지 않았습니다.
   
   
   2. 그것은 JavaScript 의 처리 속도를 높이 려는 시도였습니다(내 눈에는 이것이 변명할 수 있는 유일한 이유입니다).
      
      "엄격한 사용"이 채택된 것은 올바른 일이기 때문이 아니라 브라우저가 개발자의 요구를 충족할 수 있는
   
   
6. Javascript는 "nullable이 아닌 유형 시스템"이 아니며 Typescript는 "nullable이 아닌 유형 시스템"이 아닙니다. nullable이 아닌 형식을 선언하는 기능을 도입한다고 해서 전체 시스템이 "non-nullable"인 것은 아닙니다. Typescript의 요점이 아닙니다.

File 1:
"use notnull"
export string foo() {
    return "mygeneratedstring";
}
File 2:
export string foo() {
    return file1.foo()
}
File 3:
"use notnull"
file2.foo(); //???

실제로 동일한 구문을 사용하면서 문맥 정보 를

우리는 서클에서 논쟁하는 것 같습니다. 제 말이 이해가 안 된다면 죄송합니다만 같은 문제를 반복적으로 제기하시는 것 같아서 계속해서 답변을 드리고 있습니다.

@spion
해당 예제에서 문자열은 암시적 null이 아닙니다(--noImplicitNull 플래그가 켜져 있다고 가정합니다).

string|null|undefined는 플래그를 사용하여 내 제안에 명시적이었습니다.

내 말은 실제 시스템에서 var myString: string 는 암시적으로 var myString: (string | null | undefined); 이고 컴파일러는 다른 모든 공용체 유형이 아닌 한 typeguard를 사용하도록 강요하지 않습니다.

그렇다면 왜 파일 당 가지고 있습니까? 제 제안을 제안하는 것은 저와 다른 많은 개발자에게 중요한 하위 호환성을 손상시키지 않기 때문입니다. 그리고 프로젝트 전체에 강제로 적용할 수 있습니다.
지시문은 이전 버전과의 호환성을 깨뜨리지 않습니다(아무도 하지 않는 꽤 이상한 이유로 지시문 위치에 문자열 리터럴 'null이 아닌 사용'을 사용하지 않는 한), 또한 어느 시점에서 TypeScript는 이전 버전과의 호환성을 깨야 합니다. 그것이 semver가 메이저 버전을 정의한 이유입니다. 그러나 그것은 또 다른 이야기입니다.

내가 만들지 않은 파일을 많이 사용합니다. 특정 파일에 "null이 아닌 사용"이 있다는 것을 어떻게 알 수 있습니까? 다른 사람이 만든 100개의 파일이 있는 경우 그 100개의 파일 중 null이 아닌 파일을 외워야 합니까? (또는 다른 파일의 변수/함수를 사용할 때마다 해당 파일을 열어 확인해야 합니까?)

모든 프로젝트가 정상적으로 구성되어 있는 것처럼 가이드라인 등이 있는 프로젝트에 있다면 ... 최악의 경우에는 약간만 스크롤해야 하는 ... 그렇게 어렵지 않은 것 같습니다 ...

어디에서 멈추나요? 어디가 나쁘다고 합니까? 파일 시작 부분에 있는 하나의 문자열 또는 키워드는 파일 동작 방식을 변경해서는 안 됩니다. "use strict"가 자바스크립트에 추가되었습니다.
원하는 것을 수행할 수 있는 Javascript(예: Typescript)의 대규모 수퍼 세트가 당시에는 존재하지 않았습니다.
그것은 JavaScript의 처리 속도를 높이려는 시도였습니다(내 눈에는 이것이 변명할 수 있는 유일한 이유입니다). "use strict"가 채택된 ​​이유는 그것이 옳은 일이기 때문이 아니라 브라우저가 개발자의 요구를 충족할 수 있는 유일한 방법이기 때문입니다. 나는 typescript가 언어가 임의의 범위에서 선언된 문자열로 작동하는 방식을 근본적으로 변경하고 다른 임의의 범위에 영향을 주는 1(그런 다음 2, 3, 4)의 다른 지시문을 추가하는 것을 보고 싶지 않습니다. 정말 나쁜 언어 디자인입니다. Typescript에 "엄격한 사용"이 없고 대신 컴파일러 플래그가 있으면 만족할 것입니다.

'use strict'는 언어 동작을 변경하고 레트로 호환성을 유지하기 위해 도입되었습니다. 이는 현재 우리가 직면하고 있는 것과 똑같은 문제이며 es6 모듈과 함께 다소 사라질 것입니다(따라서 use not null은 다음 주요 버전의 typescript에서 사라질 수 있음) .

Javascript는 "nullable이 아닌 유형 시스템"이 아니며 Typescript는 "nullable이 아닌 유형 시스템"이 아닙니다. nullable이 아닌 형식을 선언하는 기능을 도입한다고 해서 전체 시스템이 "non-nullable"인 것은 아닙니다. Typescript의 요점이 아닙니다.

그 문장은 나에게 의미가없고 JavaScript에는 정적 유형 시스템이 없으므로 string 이전의 변수에 null 를 할당 할 수 있다는 사실을 쉽게 비교할 수 있습니다. 이전에 문자열이었던 변수에 5 를 할당할 수 있다는 사실에.
타이프 라이터, 자바 스크립트를 만든 타입 검사기, opinionatedly 고려하는 것이이 유일한 차이점 null 모두에 할당 할뿐만 아니라 5 .

예를 들어 파일 간에 일부 정보가 손실되었습니다. 저에게는 허용 가능한 절충안이지만 귀하의 우려를 이해할 수 있습니다.

우리는 서클에서 논쟁하는 것 같습니다. 제 말이 이해가 안 된다면 죄송합니다만 같은 문제를 반복적으로 제기하시는 것 같아서 계속해서 답변을 드리고 있습니다.

네, 동의합니다. 그에 대한 합의가 있을지 의심스럽습니다. 솔직히 말해서 저는 컴파일러를 포크하고 언젠가 메인 컴파일러 또는 그 흐름에서 끝나기를 희망하면서 자신을 위해 null이 아닌 유형을 추가하게 될 것이라고 솔직히 생각합니다. 사용할 수 있을 정도로 성숙합니다.

@griffork @spion 아이디어가 효과가 있다고 생각하는 방식은 string 플래그가 없으면 암시적 nullable number | null 이 항상 첫 번째 오버로드에서 유행하므로 두 가지 모두에서 foo(null) 경우 string 됩니다.

@RyanCavanaugh 당신은 그것이 효과가 있다고 생각합니까?

@fdecampredon

1. javascript를 최적화하기 위해 "use strict"가 도입되었습니다. 브라우저 에서
   nullable이 아닌 유형은 브라우저에서 사용할 필요가 없으므로 코드 내 지시문이 필요하지 않습니다.
2. 죄송합니다. 게시하는 것을 잊어 버린 것을 언급하고 있었는데 여기에 있습니다.

Facebook 에 따르면: "JavaScript에서 null은 암시적으로 모든 기본 유형으로 변환됩니다. 또한 모든 개체 유형의 유효한 거주자이기도 합니다."
개발자가 수행하는 모든 작업에서 nullable이 아닌 것을 명시적으로 지정하려는 이유는 nullable이 아닌 것을 사용함으로써 개발자가 자바스크립트가 작동하는 방식과 다르며 null을 허용하지 않는 유형이라는 것을 인정하기 때문입니다. (이것이 잘못될 수 있는 많은 것들이 있기 때문에) 보장되지 않습니다.
nullable이 아닌 속성은 삭제할 수 없는 속성입니다.

저는 꽤 오랫동안 Typescript를 사용해 왔습니다. 처음에는 상사에게 Javascript에서 Typescript로 변경하도록 설득하는 것이 어려웠고 브레이킹 체인지가 있을 때마다(없더라도 쉽지 않음) 업그레이드를 허용하도록 상사를 설득하는 것도 꽤 어려웠습니다. ES:Harmony가 브라우저에서 지원되면 우리는 아마 그것을 사용하고 싶을 것입니다. 지금과 Typescript가 ES:Harmony를 지원하는 시점 사이에 Typescript에서 주요 변경 사항이 발생하면(특히 null을 허용하지 않는 것처럼 널리 퍼진 경우) 나는 그 주장에서 승리할 수 있을지 의심됩니다. 모든 개발자를 재교육하는 데 드는 시간과 비용은 말할 것도 없고요(저는 "Typescript 담당자"이며 Typescript 개발자를 교육하는 것이 제 일입니다).
따라서 저는 브레이킹 체인지를 도입하는 것을 정말 반대합니다.
이전 코드를 손상시키지 않고 미래 코드에 이를 도입할 수 있는 방법이 있다면(이것이 내 제안의 이유입니다) nullable이 아닌 값을 직접 사용할 수 있다고 해도 개의치 않을 것입니다. 이상적으로는 결국 우리의 모든 코드가 변환되지만 사람을 교육하고 타사 라이브러리를 사용하는 데 드는 시간과 비용은 훨씬 줄어듭니다.

파일별 지시문 대신 기호를 사용하는 아이디어가 마음에 듭니다.

@Griffork 좋아, 내가 말했듯이 나는 당신의 걱정을 이해합니다.
이제 나는 같은 의견이 아니며 기술이 변하고 안정적인 것은 없습니다(Angular 2에 대한 전체 드라마가 그것을 증명했습니다). 그리고 저는 제가 가진 것을 고수하는 것보다 물건을 부수고 더 나은 도구를 사용하는 것을 선호합니다. 장기적으로 그것은 나에게 시간과 돈을 벌게 한다.
이제 우리 둘 다 앞서 결론을 내렸듯이 여기에서 합의를 이룰 수 있을지 의심스럽습니다. 저는 지시를 선호하고, 당신은 제안을 선호합니다.
어쨌든 내 부분에 대해 말했듯이 컴파일러에서 큰 변경 사항이 아니라고 생각하기 때문에 컴파일러를 분기하고 null이 아닌 유형을 추가하려고 합니다.
토론 감사합니다 재미있었습니다

@fdecampredon

토론해주셔서 감사합니다.

계몽 을 의미한다고 가정하고(재미있는 작품도 마찬가지입니다 :D), 토론도 즐거웠습니다 :).
포크에 행운을 빕니다. 여기에서 TS 담당자가 우리의 제안 중 일부를 최소한 기각하기를 바랍니다.

따라서 @RyanCavanaugh가 설명한 문제에 대한 제안된 솔루션을 더 자세히 설명하기 위해 null 유형과 --noImplicitNull 플래그를 추가한 후 플래그 없이 실행할 때 유형 검사기 는 수정된 동작을 갖습니다.

형식 오버로드에 |null 가 포함될 때마다(주어진 예제와 같이):

function fn(x: string): number;
function fn(x: number|null): string;

typechecker는 모든 오버로드를 취하고 목록 끝에 추가된 해당 인수 위치에 (암시적) null을 사용하여 새 변형을 만듭니다.

function fn(x: string): number;
function fn(x: number|null): string;
// implicit signature added at the end, caused by the first overload
function fn(x: null): number;

결과는 엄격한 --noImplicitNull 버전과 동일한 해석으로 나타납니다. null이 전달되면 첫 번째 일치 오버로드는 명시적 number|null 입니다. 효과적으로 명시적 null을 암시적 null보다 강력하게 만듭니다.

(예, 암시적 정의의 수가 |null 오버로드가 있는 인수의 수에 따라 기하급수적으로 증가한다는 것을 알고 있습니다. 다른 유형이 없는 경우 두 번째 패스에서 null을 "허용"하는 더 빠른 구현이 있기를 바랍니다. 일치하지만이 상황은 드물 것으로 예상하므로 어느 쪽이든 문제가 될 것이라고 생각하지 않습니다)

이와 같이 공식화되면 변경 사항이 완전히 이전 버전과 호환되고 옵트인될 것이라고 생각합니다.

다음은 나머지 동작에 대한 몇 가지 아이디어입니다.

플래그가 전달되지 않은 경우 모든 유형의 값에 대해 null을 할당하거나 값을 초기화하지 않은 상태로 두는 것도 허용됩니다.

플래그가 켜져 있으면 값이 null이 아닐 것으로 예상하는 함수나 연산자에 전달될 때까지 값을 초기화되지 않은(할당되지 않음) 또는 null로 남겨두는 것이 허용됩니다. 클래스 구성원에 대해 확실하지 않음:

• 생성자의 끝에서 초기화해야 하거나
• 초기화는 완전히 초기화하는 멤버 메서드가 호출되었는지 여부를 확인하여 추적할 수 있습니다.

명시적 null 공용체는 두 모드에서 다른 모든 공용체와 유사하게 작동합니다. 그들은 노동 조합 유형을 좁히기 위해 경비원이 필요할 것입니다.

방금 위의 _all_ 댓글을 읽었는데 정말 많습니다. 너무 많은 댓글과 5개월이 지난 후에도 여전히 같은 요점인 구문과 플래그에 대해 토론하고 있다는 점은 실망스럽습니다.

나는 많은 사람들이 대규모 코드베이스에서 컴파일러에 의한 정적 null 검사의 가치에 대해 강력한 주장을 했다고 생각합니다. 더 이상 말하지 않겠습니다(+1).

지금까지 주요 논쟁은 구문 및 수많은 기존 TS 코드 및 TS 라이브러리 정의와의 호환성 문제였습니다. null 유형을 도입하고 ?string Flow 구문을 도입하는 것이 가장 깔끔하고 자연스러워 보이는 이유를 알 수 있습니다. 그러나 이것은 string 의 의미를 변경하므로 _모든_ 기존 코드에 대한 _거대한_ 주요 변경입니다.

이 주요 변경 사항에 대해 위에서 제안한 솔루션은 컴파일러 플래그( @RyanCavanaugh 가 이것이 끔찍한 생각인 이유를 아주 잘 지적했습니다) 또는 파일별 지시문을 도입하는 것입니다. 이것은 매우 해학적인 임시방편처럼 보입니다. 게다가 나는 diff 리뷰나 거대한 파일 중간에 코드를 읽는 것을 싫어하고 내가 보고 있는 코드의 의미를 _확실히_ 즉시 알 수 없습니다. 'use strict'; 는 선례로 인용되었습니다. 우리가 반복해야 하는 것은 TS가 JS의 과거 실수를 물려받았기 때문이 아닙니다.

그렇기 때문에 "not null" 주석( string! , !string , ...)이 유일한 방법이라고 생각하고 토론에서 새로운 주장을 소개하려고 합니다. 그렇게 나쁘지 않다.

아무도 코드 전체에 앞머리( ! )를 갖고 싶어하지 않습니다. 그러나 우리는 아마도 그럴 필요가 없을 것입니다. TS는 타이핑에 대해 많은 것을 추론합니다.

1. 지역 변수
내 지역 변수에 앞머리로 주석을 달기를 기대하지 않습니다. TS가 완벽하게 주장할 수 있는 안전한 방법으로 사용하는 한 null 를 로컬 변수에 할당해도 상관 없습니다.

var x: string;  // Nullable
x.toString();  // Error: x can be undefined or null
x = "jods";
x.toUpperCase();  // Fine.
notNull(x);  // Fine

꽤 자주 유형 대신 이니셜라이저를 사용합니다.

var x = "jods";  // x: string (nullable)
notNull(x);  // Fine
x = null;  // Fine
notNull(x);  // Error

2. 함수 반환 값
매우 자주 나는 반환 값을 지정하지 않습니다. TS가 유형을 유추하는 것처럼 널 입력 가능 여부를 유추할 수 있습니다.

function() /* : string! */ {
  return "jods";
}

편집: 상속 및 함수 변수로 인한 나쁜 생각, 아래 @Griffork의 주석 참조
반환 유형을 제공하면 TS가 "not null" 주석을 완벽하게 추가할 수 있습니다.

추론된 null 허용 여부를 재정의하려는 경우(예: 메서드가 반환하지 않더라도 파생 클래스가 null을 반환할 수 있기 때문에) 유형을 명시적으로 지정합니다.

function f() : string {  // f is nullable although this implementation never returns null.
  return "abc";
}

3. 기능 매개변수
유형을 명시적으로 지정해야 하는 것과 마찬가지로 null 매개변수를 허용하지 않는 경우 표시해야 _해야 _ 합니다.

function (x: string!) { return x.toUpperCase(); } // OK
function (x: string) { return x.toUpperCase(); } // Error

이전 코드 기반에서 컴파일 오류를 방지하려면 "No implicit any"가 있는 것처럼 "Null dereference is error"라는 새 플래그가 필요합니다. _이 플래그는 컴파일러 분석을 변경하지 않고 오류로 보고된 내용만 변경합니다!_
추가할 앞머리가 많죠? 실제의 대규모 코드베이스에 대한 통계를 수행하지 않고는 말하기 어렵습니다. 선택적 매개변수는 JS에서 일반적이고 모두 nullable이므로 'not null'이 기본값인 경우 해당 주석이 필요하다는 것을 잊지 마십시오.
이러한 앞머리는 또한 현재 string 대해 알고 있는 것과 일치하여 발신자에게 null이 허용되지 않는다는 좋은 알림입니다.

4. 클래스 필드
이는 3과 유사합니다. 내용을 유추할 수 없는 상태에서 필드를 읽어야 하는 경우 선언 시 해당 필드를 nullable이 아닌 것으로 표시해야 합니다.

class C {  x: string!; }

function(c: C!) // : string! is inferred
{ return c.x; } // OK, but annotations are required

다음과 같이 이니셜라이저의 약칭을 상상할 수 있습니다.

class C {
  x! = "jods"; // Note the bang: x is inferred as !string rather than just string.
}

이니셜라이저의 기본값이 not-null이라고 하면 nullable 속성에 대해 유사한 약칭이 바람직할 수 있습니다.
다시 말하지만 기존 코드의 대부분의 필드가 nullable인지 여부를 말하기는 어렵지만 이 주석은 오늘날 개발자가 기대하는 것과 매우 일치합니다.

5. 선언, .d.ts
큰 이점은 모든 기존 라이브러리가 작동한다는 것입니다. null 및 null이 아닌 값을 입력으로 허용하며 null 가능성이 있는 값을 반환하는 것으로 가정합니다.
처음에는 일부 반환 값을 "not null"로 명시적으로 캐스팅해야 하지만, null을 반환하지 않는 경우를 나타내기 위해 정의가 천천히 업데이트됨에 따라 상황이 개선될 것입니다. 매개변수에 주석을 추가하는 것이 더 안전하지만 성공적으로 컴파일하는 데 필수는 아닙니다.

컴파일러가 유추할 수 없는 값의 "not-null" 상태를 명시하는 것이 유용할 수 있다고 생각합니다(예: 형식화되지 않은 코드를 조작할 때 또는 개발자가 프로그램의 전역 상태에 관해 일부 주장을 할 수 있는 경우) 좋을 수 있습니다:

var a: { s: string } = something(); // Notice s is nullable.
notNull(a.s); // Error
notNull(<!>a.s);  // OK, this is a shorthand "not-null" cast, because the dev knows about something().

컴파일러에게 - 간단한 방법으로 - 무언가가 null이 아님을 암시하는 기능이 바람직하다고 생각합니다. 단순하고 논리적인 구문을 사용하는 것이 더 어렵지만 기본적으로 null이 아닌 경우에도 마찬가지입니다.

죄송합니다, 이것은 매우 긴 게시물이었습니다. "기본적으로 null"을 사용하더라도 모든 코드에 주석을 추가할 필요가 없다는 아이디어를 보여주려고 했습니다. TS는 우리의 도움 없이 대부분의 코드의 정확성을 추론할 수 있습니다. 두 가지 예외는 필드와 매개변수입니다. 나는 이것이 지나치게 시끄럽지 않고 좋은 문서를 만든다고 생각합니다. 이 접근 방식의 장점은 이전 버전과 호환된다는 것입니다.

@jods4 님 이 말한 대부분에 동의하지만 몇 가지 질문과 우려 사항이 있습니다.

2) 컴파일러가 반환 유형에서 자동으로 nullable을 nullable이 아닌 것으로 변환할 수 있다면 이것을 어떻게 재정의할 수 있습니까(예: 상속 또는 대체되는 함수의 경우)?

3 & 5) 컴파일러가 nullable을 nullable이 아닌 것으로 변환할 수 있는 경우 코드 파일의 함수 서명은 이제 d.ts 파일의 동일한 함수 서명과 다르게 작동할 수 있습니다.

6) 공용체 유형을 사용할 때 뱅은 어떻게 작동/보입니까?

2) 좋은 캐치. 나는 그것이 상속(또는 '대리인')과 잘 작동할 것이라고 생각하지 않습니다.
내가 TS에 대한 경험을 하는 곳은 함수에서 반환 값을 명시적으로 입력하는 경우가 거의 없다는 것입니다. TS가 알아내고 TS가 null/not null 부분을 알아낼 수 있다고 생각합니다.

명시적으로 지정하는 유일한 경우는 확장성(상속 포함)을 위해 인터페이스 또는 기본 클래스를 반환하려는 경우입니다. Null 허용 여부는 이 설명에 아주 잘 맞는 것 같습니다.

위의 제안을 변경해 보겠습니다. 명시적으로 입력된 반환 값은 그렇게 선언되지 않은 경우 nullable이 아닌 _not_ 유추됩니다. 이것은 당신이 제안한 경우에 잘 작동합니다. 자식 클래스에서 null일 수 있는 계약에서 "not null"을 유추하는 컴파일러를 재정의하는 방법을 제공합니다.

3 & 5) 위의 변경 사항으로 더 이상 그렇지 않습니다. 그렇죠? 코드 및 정의의 함수 서명은 이제 정확히 동일한 방식으로 작동합니다.

6) 흥미로운 질문!
이것은 특히 믹스에 제네릭을 추가하는 경우 실제로 좋지 않습니다. 내가 생각할 수 있는 유일한 방법은 모든 부분이 null이 아니어야 한다는 것입니다. 제네릭 때문에 null 유형 리터럴이 필요할 수 있습니다. 제 마지막 예제를 참조하세요.

var x: number | string!; // compiler error
var x: number | string; // x can be null
var x: number! | string!; // x cannot be null
function f<T>() : number | T; // f can be null
function f<T>() : number! | T; // f is nullable if T is nullable
function f<T, G>(): T | G; // f is nullable if T or G is nullable
function f<T>(): T | null; // f is nullable even if T is not nullable.
function f<T>(): T!; // Whatever T is, f never returns null.

// Generics constraint option 1
function f<T!>(x: T!, y: T): T!; // T: not nullable type, x: not-null, y: null, f: not-null
function f<T!>(x: T!, y: T): T;  // T: not nullable type, x: not-null, y: null, f: null

// Generics constraint option 2
function f<T!>(x: T, y: T | null): T; // same as option 1.1
function f<T!>(x: T, y: T | null): T | null;  // same as option 1.2

논의를 위해 기본적으로 null이 아닌 형식을 사용하는 경우 새 구문도 발명해야 합니다. 일반 형식이 null 허용 값을 허용하지 않아야 한다는 것을 표현하는 방법은 무엇입니까?
그리고 반대로 제네릭 형식 T에 null이 포함되어 있어도 함수가 T를 반환하지 않고 null도 반환하지 않도록 지정하는 방법은 무엇입니까?

타입 리터럴은 괜찮지만 그다지 만족스럽지도 않습니다: var x: { name: string }! , 특히 둘 이상의 라인에 걸쳐 있는 경우 :(

더 많은 예:
null이 아닌 숫자의 배열 number![]
null이 아닌 숫자 배열: number[]!
아무것도 null일 수 없음: number![]!
일반: Array<number!>[]

2, 3 & 5) 나는 그것이 효과가 있을 것 같은 제안에 대한 변경에 동의합니다.
6)

function f<T>() : number | T; // f can be null
function f<T>() : number! | T; // f is nullable if T is nullable

여기서 f가 null을 반환 할 수 있음을 의미한다고 가정합니다. f가 null에 할당될 수 있다는 의미는 아닙니다.

공용체의 경우 다음 구문이 또 다른 사용 가능한 옵션이라고 생각하십니까? (조금 어리석은 것처럼 보이지만 경우에 따라 더 간결하거나 더 쉽게 따라갈 수 있습니다.)

var x = ! & number | string;

둘 다 nullable이 아님을 나타냅니다.

유형 리터럴의 경우 var x: !{name: string} 가 끝에 있는 것보다 작업하기가 더 쉬울 것이므로 리터럴 표현식의 시작 부분과 끝에 쾅을 둘 수 있습니다.

@jods4 내 "명시적 null이 암시적 null보다 우선합니다" 제안된 수정 사항에 대해 읽었습니까? 그것은 다양한 의미론적 문제를 처리한다고 생각합니다.

@그리포크
예, 물론 "nullable입니다"는 "null을 반환할 수 있음"에 대한 잘못된 표현이었습니다.

function f() {} 가 실제로 f 의 선언이라고 생각하게 만듭니다. 이는 나중에 설정할 수 있습니다... f 가 null로 설정되지 않을 것이라고 표현하고 싶습니까? ? function f!() {} ? 제 생각에는 너무 지나치는 것 같습니다. 나는 typechecker가 이것이 항상 사실이라고 가정해야 한다고 생각합니다. 어쨌든 처리할 수 없는 다른 드문 경우가 있습니다.

새로운 옵션과 관련하여 나는 그것이 조금 어리석어 보이고 유형 선언에 & 하나의 추가 기호를 도입한다는 데 동의합니다. 단일 목적으로... 그건 좋은 생각이 아닌 것 같습니다. 그리고 여러 언어에서 & AND 는 여기서 발생하지 않는 | OR 보다 높은 우선순위로 바인딩됩니다.

유형 앞에 강타를 두는 것이 가능한 대안입니다. 모든 예제를 다시 작성하여 무엇이 더 좋아 보일지 확인해야 합니다. 내가 제안한 이 필드 바로 가기가 문제가 될 것이라고 생각합니다.

class C {
  name! = "jods";  // Field inferred string, but marked not nullable.
  // Maybe we could do that instead, which works with "!T" convention:
  name : ! = "jods";
  // That kind of make sense with the proposed <!> cast.
}

@spion
예, 보았습니다.

먼저 그것이 실제로 당면한 문제를 해결하는지 확신할 수 없습니다. 따라서 fn(null) 어떤 오버로드가 바인딩되는 새 정의를 사용합니까? number 를 반환하는 '생성된' 하나? 두 번째 오버로드도 null 수락하지만 string 반환한다는 사실과 일치하지 않습니까? 아니면 오버로드 해결을 수행할 수 없기 때문에 컴파일러 오류입니까?

두 번째로 저는 우리가 다른 많은 문제를 생각해 낼 수 있다고 확신합니다. 스위치 한 번으로 소스 코드의 전체적인 의미를 바꾸는 것은 작동하지 않는다고 생각합니다. .d.ts 뿐만 아니라 사람들은 코드 재사용(라이브러리 재사용 또는 복사 붙여넣기)을 좋아합니다. 당신의 제안은 내 소스 코드의 의미론적 의미가 컴파일러 플래그에 달려 있고 그것은 나에게 매우 결함이 있는 제안으로 보인다는 것입니다.

그러나 코드가 모든 경우에 올바르게 컴파일되고 실행된다는 것을 증명할 수 있다면 저는 찬성합니다!

@jods4

두 경우 모두 두 번째 과부하가 사용됩니다.

function fn(x: string): number;
function fn(x: number|null): string; 

어떤 플래그가 사용되든 두 번째 명시적 null이 암시적(첫 번째 null)보다 우선하기 때문입니다. 따라서 플래그에 따라 의미가 바뀌지 않습니다.

null 유형은 현재 존재하지 않으므로 함께 도입되고 변경 사항은 이전 버전과 완전히 호환됩니다. 이전 유형 정의는 계속해서 정상적으로 작동합니다.

@spion
암시적 function fn(x: null): number; 의 문제는 무엇입니까? 두 번째 오버로드가 항상 우선순위를 갖는다면 어떤 플래그가 사용되더라도 이 전체 "수정"은 전혀 효과가 없습니까?

다른 질문: 오늘날 모든 lib 정의에는 "null 허용" 동작이 있습니다. 따라서 _all_ 업데이트될 때까지 "암시적으로 null" 플래그를 사용해야 합니다. 이제 이 플래그가 켜진 상태에서 프로젝트에서 null이 아닌 매개변수를 사용하는 함수를 선언하려면 어떻게 해야 합니까?

// null by default flag turned on because of 3rd party libs.
function (x: string)   // <- how do I declare this not null?
{ return x.toUpperCase(); }

수정은 확실히 효과가 있습니다. 플래그가 있거나 없는 동작을 일관되게 만들어 위에서 언급한 의미론적 문제를 수정합니다.

둘째, 타사 라이브러리에 대해 "기본적으로 null" 플래그를 사용할 필요가 없습니다. 이 기능의 가장 중요한 점은 대부분의 경우 이점을 얻기 위해 _아무것도 하지 않아도 된다는 것입니다.

문자열의 단어 수를 계산하는 라이브러리가 있다고 가정해 보겠습니다. 그 선언은

declare function wordCount(s: string): number;

코드에서 이 함수를 다음과 같이 사용한다고 가정해 보겠습니다.

function sumWordcounts(s1:string, s2:string) {
  return wordCount(s1) + wordCount(s2);
}

이 프로그램은 두 컴파일러 모두에서 전달됩니다. 암시적 null이 비활성화된 경우에도 마찬가지입니다. 코드는 완전히 이전 버전과 호환됩니다.

왜요? 오늘날과 같은 컴파일러는 이미 값을 사용하려고 하는 모든 곳에서 값이 null이 아니라는 믿음을 가지고 있기 때문입니다(이론적으로는 null일 수 있음에도 불구하고).

또한 새 컴파일러는 값을 사용하려고 할 때 값이 null이 아니라고 가정합니다. 값이 null일 수 있다고 지정하지 않았기 때문에 다르게 믿을 이유가 없습니다. 따라서 동작의 일부는 동일하게 유지됩니다. 동작의 변경 사항은 null을 할당하거나 변수를 초기화하지 않은 상태로 두고 위와 같은 함수에 해당 값을 전달하려고 할 때만 적용됩니다. 일반적으로 값을 사용하는 코드의 다른 부분을 변경할 필요가 없습니다.

이제 wordCount 의 구현을 살펴보겠습니다.

function wordCount(s) {
  if (s == '') return null;
  return s.split(' ').length
}

앗, 이 유형이 모든 것을 말해주지는 않습니다. 해당 함수가 null 값을 반환할 수 있습니다.

문제는 바로 그것이다. 우리가 원하더라도 현재 컴파일러에서 전체 이야기를 말하는 것은 불가능합니다. 물론 반환 값이 null일 수 있음을 암시적으로 나타내는 숫자라고 말합니다. 그러나 잠재적 null 값에 잘못 액세스하려고 할 때 컴파일러는 이에 대해 경고하지 않습니다. 그것은 항상 행복하게 유효한 숫자라고 생각합니다.

noImplicitNull 변경 후 동일한 유형 정의를 사용하면 여기에서 정확히 동일한 결과를 얻을 수 있습니다. 코드는 불만 없이 컴파일됩니다. 컴파일러는 여전히 wordCount가 항상 숫자를 반환한다고 행복하게 생각할 것입니다. 이전과 마찬가지로 빈 문자열을 전달하면 프로그램이 여전히 실패할 수 있습니다(이전 컴파일러는 반환된 숫자가 null일 수 있다고 경고하지 않으며 유형 정의를 신뢰하는 새 숫자도 마찬가지입니다). 그리고 동일한 동작을 원하면 코드에서 아무 것도 변경하지 않고 그대로 유지할 수 있습니다. (1)

그러나 이제 우리는 더 잘 _할 수 있습니다_: wordCount에 대한 개선된 유형 정의를 작성할 수 있습니다.

declare function wordCount(s:string):string|null;

null 반환 값을 확인하지 않고 wordCount 를 사용하려고 할 때마다 컴파일러 경고를 받습니다.

가장 좋은 점은 이 개선 사항이 완전히 선택 사항이라는 것입니다. 모든 유형 선언을 그대로 유지하고 지금과 거의 동일한 동작을 얻을 수 있습니다. 유형 선언은 더 나빠지지 않을 것입니다(2) - 필요하다고 느끼는 경우에만 더 정확하게 개선할 수 있습니다.

(1): 유형 정의를 더 좋게 만들지 않고도 여기에 이미 개선 사항이 있습니다. 새로운 유형 정의를 사용하면 실수로 null을 sumWordcounts 전달할 수 없으며 wordCount 함수가 해당 null을 .split() 하려고 할 때 null 포인터 예외가 발생합니다.

sumWordcounts(null, 'a'); // error after the change

(2): 그래, 거짓말이야. 유형 선언은 선택적 인수가 아닌 nullable 인수를 사용하는 함수의 작은 하위 집합에 대해 더 나빠질 것입니다.

선택적 인수에 대해서는 여전히 문제가 없을 것입니다.

declare function f(a: string, b?:string); 

그러나 선택 사항이 아니며 null일 수 있는 인수에는 해당되지 않습니다.

declare function f(a: string, b:string); // a can actually be null

나는 그러한 기능이 매우 드물고 필요한 수정 사항이 최소화될 것이라고 주장합니다.

@spion

수정은 확실히 효과가 있습니다. 플래그가 있거나 없는 동작을 일관되게 만듭니다.

어떤 면에서 완전한 예를 들어 줄 수 있습니까? 당신은 또한 다음과 같이 말했습니다.

두 경우 모두 두 번째 과부하가 사용됩니다.

수정 사항이 효과가 없음을 의미하는 것은 무엇입니까?

이 프로그램은 두 컴파일러 모두에서 전달됩니다. 암시적 null이 비활성화된 경우에도 마찬가지입니다. 코드는 완전히 이전 버전과 호환됩니다.

예, 두 경우 모두 오류 없이 컴파일되지만 동일한 결과는 아닙니다. sumWordCounts() 로 입력한다 number! 1 케이스와 number? 제이다. 스위치로 코드의 의미를 변경하는 것은 매우 바람직하지 _않습니다_. 앞에서 설명한 것처럼 이 변경은 오버로드 해결과 같은 전역적 영향을 미칠 수 있습니다.

또한 새 컴파일러는 값을 사용하려고 할 때 값이 null이 아니라고 가정합니다. 달리 믿을 이유가 없다.

아니! 이것이 요점입니다. 잠재적으로 null 값을 사용할 때 컴파일러가 나에게 오류를 던지기를 원합니다. 내가 코딩할 때처럼 null이 아니라고 "가정"한다면 이 기능은 쓸모가 없습니다!

동작의 변경 사항은 null을 할당하거나 변수를 초기화하지 않은 상태로 두고 위와 같은 함수에 해당 값을 전달하려고 할 때만 적용됩니다.

"위와 같은 기능"이 실제로 null을 허용하므로 이해가 확실하지 않습니다.

마지막 댓글의 끝을 읽으면서 스위치를 켤 때까지 실제 정적 null 분석을 얻을 수 없다는 인상을 받았습니다. 라이브러리 정의가 _all__ 수정될 때까지 수행할 수 없습니다. :(

일반적으로 말해서 모든 경우와 모든 것이 단어만으로 어떻게 작동하는지 완전히 이해하기 어렵습니다. 몇 가지 실용적인 예가 매우 도움이 될 것입니다.

다음은 예제와 컴파일러가 어떻게 작동하기를 원하는지입니다.

null을 반환하지 않는 yes(): string! 함수와 null을 반환할 수 있는 no(): string? 함수가 있는 라이브러리를 가정합니다.

.d.ts 정의는 다음과 같습니다.

declare function yes(): string;
declare function no(): string;

정적으로 확인된 null을 활용하고 기존 라이브러리 정의를 사용하는 대규모 프로젝트를 TS에서 생성할 수 있기를 원합니다. 또한 모든 라이브러리가 올바른 nullness 정보로 업데이트되는 상황으로 _점진적으로_ 전환할 수 있기를 원합니다.

위에서 제안한 not null 수정자 ! 사용하여 다음과 같이 할 수 있습니다.

function x(s: string!) {  // inferred : string, could be explicit if we want to
  return s.length === 0 ? null : s;  // no error here as s is declared not null
}

x(no());  // error: x called with a possibly null parameter
y(<!>yes());  // no error because of not null cast. When .d.ts is updated the cast can be dropped.

그것이 당신의 아이디어와 어떻게 작동할까요?

이 스레드는 너무 긴 토론(댓글 130개!)으로 모든 사람이 언급한 아이디어, 제안 및 문제를 따르기가 매우 어렵습니다.

제안된 구문, TS에서 허용하는 것, 오류가 무엇인지 등을 포함하여 제안으로 외부 요점을 만들 것을 제안합니다.

@spion 아이디어에는 컴파일러 플래그가 포함되므로 각 코드 조각에 대해 플래그를 설정하고 설정하지 않은 상태에서 TS 동작을 문서화해야 합니다.

!T null이 아닌 마커의 요지는 다음과 같습니다.
https://gist.github.com/jods4/cb31547f972f8c6bbc8b

다음과 같은 차이점이 있지만 위의 내 의견과 대부분 동일합니다.

• 나는 함수 매개변수의 'null이 아닌' 측면이 컴파일러에 의해 안전하게 유추될 수 있다는 것을 알아차렸습니다(해당 통찰력을 제공한 @spion 덕분에).
• 나는 특히 반환 값을 추론에 대해, @Griffork 주석을 포함하고 나는 시도 !T 대신 T! .
• 예를 들어 생성자 동작에 대한 몇 가지 섹션을 추가했습니다.

자유롭게 의견을 제시하고, 포크하고, 대안 제안을 만드십시오( ?T ).
앞으로 나아가도록 노력합시다.

@jods4

두 경우 모두 두 번째 과부하가 사용됩니다.

수정 사항이 효과가 없음을 의미하는 것은 무엇입니까?

1. 이는 두 플래그에 대해 언어 의미 체계를 일관되게 만들기 위해 오버로드 해결이 변경되었음을 의미합니다.

예, 두 경우 모두 오류 없이 컴파일되지만 동일한 결과는 아닙니다. sumWordCounts()는 숫자로 입력됩니다! 하나의 경우와 숫자로? 두 번째에서. 스위치로 코드의 의미를 변경하는 것은 매우 바람직하지 않습니다. 앞에서 설명한 것처럼 이 변경은 오버로드 해결과 같은 전역적 영향을 미칠 수 있습니다.

1. 내 제안에 number! 이 없습니다. 두 경우 모두 유형은 단순히 number 입니다. 즉, null 값을 제외하고 오버로드 해결이 계속 정상적으로 작동함을 의미합니다. 이 경우 명시적 null에 대한 새로운 동작이 암시적 null보다 우선하여 이전 버전과 호환되는 방식으로 의미 체계를 정규화합니다.

아니! 이것이 요점입니다. 잠재적으로 null 값을 사용할 때 컴파일러가 나에게 오류를 던지기를 원합니다. 내가 코딩할 때처럼 null이 아니라고 "가정"한다면 이 기능은 쓸모가 없습니다!

1. 내가 표현하려고 했던 요점은 (유형 선언 측면에서) 기능의 하위 호환성이 거의 없다는 것입니다. 사용하지 않으면 이전과 똑같은 동작을 하게 됩니다. null 유형 값이 반환될 수 있는 가능성을 표현하는 데 사용하려는 경우 이제 할 수 있습니다.

컴파일러가 이전에 object 및 string 유형의 값에 대해 string 유형을 사용하여 모든 개체에 대한 모든 문자열 메서드를 허용하고 절대 확인하지 않는 것과 같습니다. 이제 Object 대해 별도의 유형을 갖게 되며 대신 해당 유형을 사용하여 문자열 메소드를 항상 사용할 수 있는 것은 아님을 나타낼 수 있습니다.

"위와 같은 기능"이 실제로 null을 허용하므로 이해가 확실하지 않습니다.

이 기능을 살펴보겠습니다.

function sumWordcounts(s1:string, s2:string) {
  return wordCount(s1) + wordCount(s2);
}

새 컴파일러 플래그에서는 sumWordCounts(null, null); 와 같은 null 값으로 호출할 수 없으며 이것이 유일한 차이점입니다. wordCounts 의 정의는 문자열을 취하고 숫자를 반환한다고 말하므로 함수 자체가 컴파일됩니다.

마지막 댓글의 끝 부분을 읽으면서 모든 라이브러리 정의가 수정될 때까지 할 수 없는 스위치를 켤 때까지 실제 정적 null 분석을 얻을 수 없다는 인상을 받았습니다. :(

대부분의 코드는 null/undefined인지 확인하고 코드베이스 전체에서 해당 값이 완전히 관련 없는 위치로 전파되는 것을 방지하기 위해 오류를 발생시키는 것 외에는 null 또는 정의되지 않은 값을 실제로 처리하지 않습니다. 디버그합니다. 여기 저기에 선택적 인수를 사용하는 몇 가지 기능이 있습니다. 이 기능은 인식할 수 있고 새 스위치로 적절하게 모델링할 수 있습니다. 함수가 내 예와 같이 null 값을 반환하는 경우는 많지 않습니다(대표 사례가 아닌 기능에 대한 요점을 설명하기 위해서만 사용했습니다).

내가 말하고자 하는 것은 대부분의 유형 정의가 올바른 상태로 유지될 것이며 수정해야 하는 몇 가지 남아 있는 경우에 대해 null 대소문자가 중요하지 않다고 판단되면 수정하지 않도록 선택할 수 있다는 것입니다. 관심이 있다면 그에 따라 유형을 변경하십시오. 이는 필요할 때마다 더 강력한 보증을 제공한다는 typescript의 목표와 완전히 일치합니다.

좋습니다. 기존 유형 정의는

declare function yes(): string;
declare function no(): string;

기능이 추가되기 전에 코드가 작성되었다고 가정해 보겠습니다.

function x(s: string) {
  return s.length === 0 ? null : s;
}

새 컴파일러에서 동작은 이전 컴파일러와 정확히 동일합니다.

x(no());  // no error
x(yes());  // no error

x()의 결과와 같이 컴파일러가 null일 수 있다는 것을 알고 있는 것을 시도하지 않는 한

x(x(no())) // error, x(something) may be null

no() 보고 null을 반환하는 경우가 드물기 때문에 이를 모델링하지 않거나 유형 정의를 수정할 수 있습니다.

이제 제안이 어떻게 되는지 살펴보겠습니다. 외부 라이브러리에 닿는 모든 단일 코드 라인은 중단됩니다. 위와 같이 완벽하게 유효한 유형 정의를 가진 함수도 중단됩니다. 모든 단일 인수 주석을 모든 곳에서 업데이트하고 ! 를 추가하여 컴파일러가 불평하지 않도록 하거나 모든 곳에서 null 검사를 추가해야 합니다.

결론은 TypeScript의 유형 시스템이 현재 잘못되었다는 것입니다. null 값에 대한 이중 해석이 있습니다.

T 유형의 변수에 null을 할당하거나 T 유형이 필요한 인수로 null을 전달하려고 하면 유형이 T|null 것처럼 작동합니다.

T 유형의 값을 사용하려고 하면 유형이 T 이고 null 가능성이 없는 것처럼 작동합니다.

귀하의 제안은 모든 일반 유형 T 을 항상 T|null 로 취급하도록 제안합니다. 광산은 T 로 취급하는 것이 좋습니다. 둘 다 의미를 변경합니다. 둘 다 컴파일러가 "올바르게" 작동하도록 합니다.

내 주장은 "단지 T " 변형이 보기보다 훨씬 덜 고통스럽고 대다수의 코드와 조화를 이룬다는 것입니다.

편집: 나는 당신의 제안이 "!" 없이 유형을 계속 취급할 수 있다는 것을 깨달았습니다. 또는 "?" 이전과 같은 방식으로. 이전 버전과 호환되지만 이점을 얻으려면 많은 작업이 필요합니다(대부분의 코드가 단순히 검사/던지기 이외의 null 값을 처리하지 않기 때문입니다.

@spion

1. 두 플래그에 대해 언어 의미 체계를 일관되게 만들기 위해 오버로드 해결이 변경되었음을 의미합니다.

당신은 단지 같은 사실을 말하고 있지만 그것이 어떤 경우에 어떤 방식으로 다루어지는지는 여전히 불분명합니다.
그래서 구체적인 예를 들어 물었다.

1.제 제안서에 number! 이(가) 없습니다. 두 경우 모두 유형은 단순히 number 입니다.

그것은 정확하지 않습니다. 구문은 다르지만 기본 개념은 동일하다는 것을 알고 있습니다. 내가 number! 라고 말할 때 나는 널이 아닌 숫자 유형을 강조하고 있습니다. 이것은 귀하의 제안에서 단순히 number 입니다. 그리고 두 번째 경우는 귀하의 경우 number 가 아니라 number | null 입니다.

대부분의 코드는 null/undefined인지 확인하고 코드베이스 전체에서 해당 값이 완전히 관련 없는 위치로 전파되는 것을 방지하기 위해 오류를 발생시키는 것 외에는 null 또는 정의되지 않은 값을 실제로 처리하지 않습니다. 디버그합니다. 여기 저기에 선택적 인수를 사용하는 몇 가지 기능이 있습니다. 이 기능은 인식할 수 있고 새 스위치로 적절하게 모델링할 수 있습니다. 함수가 내 예와 같이 null 값을 반환하는 경우는 많지 않습니다(대표 사례가 아닌 기능에 대한 요점을 설명하기 위해서만 사용했습니다).

나는 이와 같은 설명이 많은 가정과 지름길을 만든다고 생각합니다. 그렇기 때문에 진행을 위해서는 코드, 구문 및 시스템 작동 방식에 대한 설명이 포함된 보다 구체적인 예제로 넘어갈 필요가 있다고 생각합니다. 당신은 말한다:

대부분의 코드는 null/undefined인지 확인하고 오류를 발생시키는 것 외에는 null 또는 정의되지 않은 값을 실제로 처리하지 않습니다.

매우 논쟁의 여지가 있습니다.

여기에 선택적 인수를 사용하는 몇 가지 기능이 있습니다.

더욱 논쟁의 여지가 있습니다. JS 라이브러리는 그러한 예제로 가득 차 있습니다.

, 인식할 수 있고 새 스위치로 그에 따라 모델링할 수 있습니다.

이것은 큰 지름길이기 때문에 보다 구체적인 제안을 하십시오. 이것이 실제 JS 코드로 향하는 위치를 알 수 있다고 생각하지만 declare function(x: {}); 내부 또는 interface 내부의 선택적 인수를 어떻게 "인식"하시겠습니까?

함수가 내 예와 같이 null 값을 반환하는 경우는 많지 않습니다.

다시 매우 논쟁의 여지가 있습니다. 많은 함수가 null 또는 undefined 값을 반환합니다. find (항목을 찾을 수 없는 경우), getError (오류가 없는 경우) 등 ... 더 많은 예를 보려면 표준 브라우저 API를 살펴보십시오. _plenty_를 찾을 수 있습니다.

내가 말하고자 하는 것은 대부분의 유형 정의가 올바른 상태로 유지될 것이라는 것입니다.

내 이전 의견에서 알 수 있듯이 나는 그것에 대해 확신하지 못합니다.

수정해야 하는 나머지 몇 가지 사례의 경우 null 사례가 중요하지 않은 경우 수정하지 않거나 관심이 있는 경우 그에 따라 유형을 변경할 수 있습니다. 이는 필요할 때마다 더 강력한 보증을 제공한다는 typescript의 목표와 완전히 일치합니다.

이 시점에서 이 진술은 나에게 사소한 것처럼 보이지 않습니다. 그것이 어떻게 작동하는지에 대한 구체적인 예를 들어주실 수 있습니까? 특히 _점진적으로_ 부분.

이제 제안이 어떻게 되는지 살펴보겠습니다. 외부 라이브러리에 닿는 모든 단일 코드 라인은 중단됩니다. 위와 같이 완벽하게 유효한 유형 정의를 가진 함수도 중단됩니다. 모든 단일 인수 주석을 모든 곳에서 업데이트하고 ! 를 추가하여 컴파일러가 불평하지 않도록 하거나 모든 곳에 null 검사를 추가해야 합니다.

이것은 거의 완전히 잘못된 것입니다. 제가 쓴 요지를 잘 읽어주세요. 실제로는 null이 아닌 주석이 거의 필요하지 않다는 것을 알 수 있습니다. 그러나 _하나의_ 주요 변경 사항이 있습니다. 그렇습니다.

라이브러리 정의를 사용하는 기존 코드 기반을 가져와서 코드를 변경하지 않고 내 제안으로 컴파일하려고 한다고 가정합니다.

• 주석이 없어도 null 분석 이점을 많이 얻을 수 있습니다(Flow 컴파일러에서 얻는 것과 거의 동일한 방식).
• 한 가지 문제가 발생합니다. 라이브러리 함수의 반환 값을 사용하면 null이 반환되지 않는다는 것을 알 수 있습니다.

declare function f(): string; // existing declaration, but f will never return null.
var x = f();
x.toUpperCase();  // error, possibly null reference.

장기적 수정은 라이브러리 정의를 더 정확하게 업데이트하는 것입니다. declare function f(): !string;
단기 수정은 null이 아닌 캐스트를 추가하는 것입니다: var x = <!>f(); .
그리고 많은 종속성이 있는 대규모 프로젝트를 더 쉽게 업그레이드할 수 있도록 "no implicit any"와 유사한 컴파일러 플래그를 추가하는 것이 좋습니다. "가능한 null 참조를 경고로 처리". 즉, 새 컴파일러를 사용하고 라이브러리가 정의를 업데이트할 때까지 기다릴 수 있습니다. 참고: 귀하의 제안과 달리 이 플래그는 컴파일러 의미를 변경하지 않습니다. 오류로 보고된 내용만 변경합니다.

내가 말했듯이 나는 우리가 이 토론에서 진전을 이루고 있는지 확신할 수 없습니다. 내 요지를 보고 플래그의 두 상태 모두에서 자신의 아이디어, 코드 예제 및 동작으로 하나를 만들 것을 제안합니다. 우리는 모두 코더이므로 더 명확해질 것이라고 생각합니다. 또한 고려해야 할 엣지 케이스가 많이 있습니다. 그렇게 하고 나면 특별한 상황에 대해 물어볼 수 있는 질문이 많이 있지만 정확한 정의 없이 개념과 아이디어에 대해 토론하는 것은 실제로 아무 소용이 없습니다.

이 130개 이상의 댓글 문제에서 진행 중인 다양한 문제에 대해 너무 많은 토론이 있습니다.

여기에서 _일반적인_ 토론을 계속할 것을 제안합니다.

TS에서 null이 아닌 유형을 구현할 수 있는 구체적인 제안에 대한 논의를 위해 각각 단일 설계 제안에 대한 새로운 문제를 열 ​​것을 제안합니다. !T 구문을 논의하기 위해 #1800을 만들었습니다.

@spion 디자인에 대한 문제도 생성하는 것이 좋습니다.

많은 사람들이 null이 아닌 유형을 원합니다. 새로운 언어(예: Rust)에서는 쉽지만 기존 언어에서는 개조하기가 매우 어렵습니다(사람들은 오랫동안 .net에서 null이 아닌 참조를 요청해 왔습니다. 그들을). 여기에 있는 댓글을 보면 사소한 문제가 아님을 알 수 있습니다.
Flow는 이것이 TS를 위해 할 수 있다고 확신했습니다. 그것을 실현하도록 노력합시다!

@jods4 유감이지만 귀하의 제안은 null이 아닌 유형과 관련이 없으며 일종의 제어 흐름 분석과 관련이 있으며 거의 ​​예측할 수 없으며 레트로 호환성을 완전히 깨뜨립니다 (사실 대부분의 코드는 유효합니다 1.4 ts는 요점에 설명된 규칙에 따라 실패합니다).
나는 토론이 아무데도 가지 않고 있다는 사실과 130개 이상의 댓글이 아마도 너무 많다는 사실에 동의합니다. 그러나 아마도 여기에 토론하는 두 그룹의 사람들이 있기 때문일 것입니다.

• null이 아닌 유형이 기본값이어야 한다고 생각하고 그렇게 하는 방법을 찾고자 하는 사람들(플래그 또는 기타 메커니즘을 통해)
• null이 아닌 유형을 원하지 않고 도입을 피하거나 새로운 구문으로 푸시하려는 사람들.

그 두 그룹의 사람들은 오랫동안 서로의 주장에 귀를 기울이지 않고 멈추었고 결국 우리에게 필요한 것은 TS 팀의 관점입니다. 그때까지 저는 개인적으로 이 주제에 대한 더 많은 논의를 중단하겠습니다.

@fdecampredon
내 요점에 대한 부분과 관련하여 #1800에 귀하의 주장을 복사하여 붙여넣었습니다. 진심으로 관심이 있다면 왜 그것이 나쁜 디자인인지 논의할 수 있습니다. 나는 당신의 관점을 정말로 이해하지 못하지만 여기서 논의를 시작하고 싶지 않습니다. 그래서 내가 처음에 #1800을 만든 이유입니다.

이 스레드와 관련하여 논의가 아무데도 진행되지 않는다는 데 동의합니다...

내 이전 의견에서 알 수 있듯이 나는 그것에 대해 확신하지 못합니다.

글쎄, 나는 그것을 다른 방식으로 설명하는 방법을 정말로 모릅니다. 이미 몇 번 설명했습니다. 한 번 더 시도하겠습니다.

지금 당신은 그것을 표현할 수 없습니다

declare function err():string;

null을 반환합니다. 불가능합니다. 왜냐하면 typescript는 항상 기꺼이 err().split(' ') 을 할 수 있기 때문입니다. "그것은 유효하지 않을 수 있습니다"라고 말할 수 없습니다.

이 변경 후에 string 를 ?string 또는 string|null 로 변경하여 다음을 수행할 수 있습니다.

하지만 그렇게 하지 않으면 변경 전에 가지고 있던 _아무것도 잃지 않습니다_:

변경 전에 null 검사가 없었고 이후에도 없습니다(아무것도 하지 않는 경우). 나는 이것이 대부분 이전 버전과 호환된다고 주장했습니다. 물론 더 큰 코드베이스에서 시연해야 합니다.

차이점은 다음과 같습니다. 변경 전에 null 검사를 강제할 수는 없지만 변경 후에는 _할 수 있습니다.

@fdecampredon 이 문제에 대해 많은 오해가 있고 이 기능을 활용하는 것이 얼마나 "어렵고" "엄격한" 것인지에 대해 많은 오해가 있기 때문에 여전히 이 주제에 대해 논의합니다. 나는 많은 잠재적인 문제가 심각하게 과장되었다고 생각합니다. 포크에서 --noImplicitNull 의 기본 변형을 시도하고 구현해야 할 것입니다. 다음 기간에 시간을 찾을 수 있을지 확신할 수 없지만 그렇게 하면 시도해 보겠습니다. , 재미있는 프로젝트처럼 들립니다.

@spion , 나는 null이 null 키워드로 선언되는 것에 대해 모두

그리고 @fdecampredon 내 유일한 요청은 큰 변화가 없는 것, 특히 오류가 잘못된 위치에 표시되는 것이었습니다.

현재 예제에서 @spion 이 할당되지 않은 경우 지역 변수가 null 허용 및 함수 매개변수로 변환된다고 가정한다면 지금과 같은 방식으로 Typescript를 계속 코딩할 수 있다고 생각합니다. null일 수도 있습니다. 음, 이전에 nullable 초기 함수 매개변수를 사용했던 그 예를 제외하고.

@spion
마지막 댓글에서 제가 이해한 내용이 이전에 이해한 내용과 많이 다릅니다...

따라서 : string 는 " <any> 가 유형 정확성을 검사하지 않는 것처럼 null 여부를 검사하지 않는 이전 문자열 유형"입니다.

새 구문 : string | null 은 이전에 존재하지 않았으므로 이전 버전과 호환되며 null 검사 없이 이 형식에 액세스하면 오류가 발생합니다.

흥미롭고 모든 의미를 파악하기 어렵습니다. 한동안 생각해봐야겠네요.

가장 먼저 떠오르는 질문은 입력 값(예: 함수 매개변수)에 제약 조건을 적용하는 방법입니다.

declare f(x: string): void;
f(null);

이게 정상인가요 오류인가요? 괜찮다면 어떻게 오류를 만들 수 있습니까?

_나는 여전히 이 토론에서 잃어버린 아이디어가 있다고 생각합니다. 이 아이디어로 새로운 문제를 열고 싶지 않습니까? 우리는 거기에 대해 논의할 수 있습니다._

@jods 오류가 될 것입니다.

declare f(x: string): void; //string must not be null.
declare f(x: string|null): void; //string may be null (not sure about undefined here).
declare f(x?: string): void; //I assume x may be null or undefined.

@jods4 하나의 주제에 대해 여러 문제를 만들 필요가 없다고 생각합니다. 그러면 10개의 다른 제안으로 이동하여 어떤 일이 발생했는지 확인해야 하므로 상황을 추적하기가 더 어려워질 것입니다/10개의 다른 제안에 구독 . 그리고 그들은 모두 소개에 다른 제안에 대한 링크를 포함해야 합니다. 그래야 null 허용 여부를 찾는 모든 사람이 하나를 보고 투표하는 것이 아닙니다.

@fdecampredon 많은 게시물과 해결되지 않은 사항이 있다는 것을 알고 있지만 그렇다고 해서 모두가 좋아하는 솔루션을 찾는 것을 중단해야 한다는 의미는 아닙니다. 우리가 여전히 이에 대해 이야기하고 스스로 설명한다는 사실이 마음에 들지 않는다면 해당 주제에서 구독을 취소하는 것을 환영합니다.

@그리포크
하지만 마법의 깃발을 켠 후에야, 그렇지?
따라서 플래그를 끄면 이전에 존재하지 않았던 새로운 nullable 유형을 제외하고 검사되지 않은 코드가 있습니다. 그런 다음 플래그를 켜면 모든 유형이 nullable이 아니며 확인됩니까?

나는 최종 결과가 아마도 최고의 솔루션이라고 생각합니다. _하지만 그것은 오늘날 존재하는 거의 모든 코드를 깨고 있습니다._ 300K 라인의 코드가 있다고 상상해보십시오... 플래그를 켜기 전에 유형이 실제로 nullable인 모든 곳에 nullable 주석을 추가해야 합니다. 정말 대단한 일입니다.

내가 올바르게 이해한다면 이것은 새 프로젝트( .d.ts 가 업데이트되면)에 좋지만 기존 코드에는 매우 고통스럽습니다.

@Griffork 이 단일 문제와 긴 주석 스레드에 대한 내 문제는 단일 제안에 대해 집중적인 토론을 하기가 매우 어렵다는 것입니다. 3~4개의 문제를 구독하는 것은 큰 문제가 아니며 각 문제에 대한 적절한 컨텍스트가 있습니다.

@spion 의 원래 제안에는 마법의 깃발이 없었습니다. typescript가 작동하는 방식에 대한 핵심적인 변경이었습니다.

예, 하지만 이 토론에 참여하는 사람은 이전에 나온 모든 내용을 읽어야 합니다. 사람들이 이전에 나온 모든 내용을 읽어서는 안 된다고 생각한다면(따라서 잠재적으로 동일한 제안을 제안할 수 있음) _그러면_ 나눌 수 있습니다. 하지만 동의하지 않습니다. 한 장소에 있는 것의 요점은 비록 우리가 다른 세부사항이나 다른 가능한 구현에 대해 이야기하고 있었지만 우리는 모두 같은 것에 대해 이야기하고 있다는 것 입니다.
다른 주제가 아니라 같은 주제입니다.
모든 대화는 중앙 집중화되어 있으며 응답하지 않음으로 인해 묻히지 않습니다.

많은 제안이 현재 논의 중인 다양한 세부 사항을 자주 다루기 때문에 구현 세부 사항으로 이 대화를 나눌 수도 없습니다.

제안서를 서로 분리한다는 것은 누군가가 결함을 발견하면 여러 다른 스레드로 이동하여 작성해야 함을 의미합니다. 그러면 사람들은 서로의 실수로부터 배우지 않고, 사람들은 한 토론에 자신을 격리하고 다른 토론에서 요약된 실수를 반복할 수 있는 능력(그들이 할 것입니다)을 가지고 있습니다.

요점은: 대화를 나누면 연결된 다른 모든 게시물의 모든 내용을 읽을 수 없는 시청자 때문에 사람들이 많은 게시물을 반복해야 한다는 것입니다(모든 관련 게시물이 다른 모든 게시물을 연결한다고 가정). ).

또한 @jods4는 null을 할당할 때만

null을 할당할 수 없어야 하는 모든 단일 정의를 사용하고 null을 허용하지 않는 유형의 이점을 얻기 전에 확인/수정해야 하는 제안보다 중요한 변경 사항이 훨씬 적습니다.

다음은 @jods4 및 @spion 의 제안에 대한 "업그레이드" 프로세스의 예입니다(필요한 플래그가 켜져 있다고 가정).

function a(arg1: string): string;
a("mystr").toLowerCase(); //errors in <strong i="11">@jods4</strong>'s proposal because a may return null.
a("mystr").toLowerCase(); //fine in <strong i="12">@spion</strong>'s proposal.

a(null).toLowerCase(); //fine in <strong i="13">@jods4</strong>'s proposal because a may accept null.
a(null).toLowerCase(); //errors in <strong i="14">@spion</strong>'s proposal since a doesn't accept null.

결국 둘 다 변경 사항을 깨고 있습니다. 둘 다 디버그하기 힘들지만 변수 선언 대신 변수 사용 시 오류가 발생합니다. 차이점은 하나는 null이 무언가에 할당될 때(@spion) 오류가 발생하고 다른 하나는 null이 무언가에 할당되지 않을 때(@jods4) 오류가 발생한다는 것입니다. 개인적으로 나는 사물에 null을 할당하지 않을 때보다 훨씬 덜 자주 null을 할당하므로 @spion 은 내가 작업할 수 있는 변경 사항이 적습니다.

내가 좋아하는 다른 것들:

• 변수 유형이 동적으로 변경되지 않습니다. 내가 원한다면 흐름을 사용할 것입니다.

var s: string;
s.toUpperCase(); // error
var t = (s || "test").toUpperCase(); // ok. Inferred t: string
yes(t);  // ok
t = no();
yes(t);  // error

개인적으로 유형의 암시적 변경이 아니라 no()를 호출하면 오류가 발생하고 싶습니다.

• 일부 기호보다 null이라는 단어가 포함된 Nullable은 읽기 쉽고 기억하기 어렵습니다. 정말로 ! "not-null"이 아닌 "not"에 사용해야 합니다. 나는 두문자어가 싫은 것처럼 기호가 하는 일을 기억해야 하는 것을 싫어합니다. 두문자어를 기억할 수 없고 작업 속도가 크게 느려집니다.

@jods4 현재 대화가 사람들이 따라잡기

@Griffork 솔직히 다 읽었는데 많은 분들이 읽으

nullable인 항목이 있을 때마다 중요한 변경 사항입니다(이는 특정 시점에서 null이 할당됨을 의미합니다. 그렇지 않으면 실제로 nullable이 아님). null이 함수에 할당/전달되지만 수정 사항은 선언 시 오류가 보고됩니다. 여기에는 함수 선언, 변수 선언, 클래스의 필드 선언이 포함됩니다... 많은 것들이 잠재적으로 검토되고 수정되어야 합니다.

@jods4 실제 핵심 정보가 아니라 실현되지 않은 하위 토론이 분기되어야 합니다. 하지만 지금 돌아가서 바꾸기에는 너무 늦었습니다.

@spion '-nonImplicitNull' 플래그가 있는 @RyanCavanaugh 문제에 대한 더 간단한 솔루션이 있다고 생각합니다. 아이디어는 매우 간단합니다. ?type type|null 또는 type|undefined 허용하지 않아야 합니다.

@fdecampredon 그런 다음 사용 가능한 모든 라이브러리의 두 가지 버전이 필요하고 최신 상태로 유지해야 합니다.
또한 코드를 시도하고 더 엄격한 프로젝트의 코드에 의존하는 테스트를 실행하기 위한 하나의 비엄격한 프로젝트가 있는 프로세스를 종료합니다.

@jods4

declare f(x: string): void;
f(null);

제안된 --noImplicitNull 플래그를 사용하면 예, 오류가 됩니다.

나는 아직 공식 제안을 여는 것이 편하지 않습니다. 최소한 몇 가지 사고 실험을 더 하거나 포크에서 아이디어의 더 간단한 버전을 구현하려고 합니다.

!T 제안이 실제로 많은 코드도 깨뜨릴 것이라는 사실을 알게 되었습니다. 기존 유형의 의미가 변경되었기 때문이 아니라 새로운 분석이 여러 위치에서 오류를 발생시키기 때문입니다.

그래서 나는 그것을 닫았다. 많은 코드를 깨는 경우 다른 접근 방식을 선호하는 것이 더 깔끔해 보입니다.

나는 이제 많은 기존 코드를 깨뜨리지 않고 이 기능을 도입할 방법이 없다고 확신합니다. 이것은 아직 작성되지 않은 모든 코드에 여전히 좋고 아마도 오래된 코드는 컴파일러에 의한 null 검사의 이점 없이 계속 컴파일할 수 있습니다. 이것이 바로 오늘날과 같습니다.

이 단점과 장점에 대한 공식 TS팀의 입장이 궁금합니다.

"기본적으로 모든 것을 null 허용하지 않도록 설정"만큼 큰 휴식을 취하지는 않을 것입니다. 분명히 버그인 경우에 새로운 오류를 _only__ 발행하는 제안이 있었다면, 그것은 테이블에 있을 수 있지만, 그런 제안은 오기 힘든 것입니다 :wink:

영향 범위가 더 작으면 null 를 인수로 전달할 때 과부하 해결의 변경 사항(예: 정확한 동작이 반드시 즉시 명확하지 않은 경우)의 경우 이야기가 달라질 수 있습니다.

:+1: 정상인 감지됨:

기존의 작동 방식에는 변경 사항이 없지만 공용체에 null 유형이 도입되어 변수를 사용하기 전에(또는 null이 아닌 유형의 변수에 할당해야 함) 변수를 보호해야 합니까? 기본 동작을 사용하면 정상적으로 입력된 변수와 null로 입력된 변수에 여전히 null을 할당할 수 있지만 올바르게 마크업된 경우 null을 반환할 수 있는 함수는 강제로 캐스트됩니다.

이렇게 하면 주요 변경 사항이 없지만 모범 사례를 사용하면 추론된 입력 및 우수한 코딩 사례 모두를 사용하여 입력 시스템에서 여전히 많은 버그를 선택할 수 있습니다.

그런 다음 (나중에 아마?) 당신은 (이 다소 작품 플래그로의 제안이 활성화 @spion처럼) 자신의 입력의 한 부분으로 널 (null)이없는 변수에 할당되는 것을 방지를 null하는 --noImplicitNullCast 플래그를 추가 할 수 있습니다.

나는 이것이 모든 일반 타이핑과 --noImplicitAny 플래그의 추가와 크게 다르지 않을 것이라고 상상합니다.

@그리포크
패키지의 전반부( null 유형 추가 및 보호 없이 역참조 금지)는 100% 호환되지 않습니다. 당신은 당신이 생각하는 것보다 더 많은 코드를 깨뜨릴 것입니다. 이걸 고려하세요:

이 새로운 기능으로 내장된 것을 포함하여 많은 lib defs가 업데이트될 것입니다. 가능한 반환 값으로 null을 명시적으로 포함하도록 일부 서명을 변경했다고 가정해 보겠습니다. 몇 가지 예:

interface Array<T> {
  find(predicate: (T) => bool) : T | null;
  pop() : T | null;
}
interface Storage {
  getItem(key: string) : any | null;
}

: 많은 등의 API가 있습니다 find 반환 undefined 에는 배열 요소가 조건과 일치하지 않는 경우, pop 반환 undefined 배열이 비어있는 경우, localStorage.getItem 또는 sessionStorage.getItem 키를 찾을 수 없는 경우 둘 다 null 반환합니다.

다음 코드는 합법적이고 이전에 완벽하게 컴파일되었습니다. 이제 오류와 함께 중단됩니다.

var xs: string[];
if (xs.length > 0) return xs.pop().trim();  // error xs.pop() may be undefined (false positive)

var items : { id: number }[];
var selectedId : number;
// Assume we are sure selectedId is amongst items
var selectedItem = items.find(x => x.id === selectedId);
selectedItem.toString(); // error selectedItem may be undefined (false positive)

localStorage 에서 거기에 있는 것을 가져오는 경우에도 같은 생각입니다. 주변에 그런 코드가 많이 있으며 이제 컴파일하고 컴파일러에 알리기 위해 캐스트(또는 일부 새로운 구문)가 필요합니다. 이것이 null이 아니라고 가정하고 내가 무엇을 하는지 알고 있습니다.

여기에는 몇 가지 실제 버그가 포함됩니다. 그러나 여기에는 많은 오탐지가 포함되며 이는 주요 변경 사항입니다. 100K+ LOC에서는 사소한 컴파일러 업그레이드가 아닙니다.

이것은 아마도 작동할 수 있는 유일한 접근 방식이 다음과 같다는 것을 의미합니다. 처음부터 새로 작성된 코드 또는 마이그레이션된 이전 코드는 null 검사를 최대한 활용합니다. 레거시 코드는 전혀 이점이 없습니다. 이것은 컴파일러 옵션(--enableNullAnalysis)에 의해 구동되며 "전환" 또는 "프로그레시브" 마이그레이션 경로가 없습니다.

네. 그러나 항상 프로젝트의 lib.d.ts를 고정하거나 이전 프로젝트를 가져올 수 있습니다.
새로운 타이핑은 오래된 코드를 깨뜨릴 것입니다. 어쨌든 그렇게 될 것입니다. 도입될 때 거의 모든 새로운 타이핑은 이전 코드가 올바르게 작동하기 위해 어떤 식으로든 업데이트되어야 합니다(예: 공용체, 제네릭).
이 변경은 업데이트를 무시하거나 라이브러리/코드 정의를 고정하려는 사람들이 고통을 겪지 않는다는 것을 의미합니다.
이론적으로 이러한 기능을 사용하는 대부분의 코드는 어쨌든 보호되어야 합니다(일반적으로 큰 코드베이스에 있음). 보호하지 않으면 코드에 숨어 있는 버그가 있기 때문입니다. 따라서 이 변경은 광범위한 주요 변경을 유발하는 것보다 오류를 포착할 가능성이 더 큽니다.

편집하다
@jods4 우리가 이 변경을 통해 감지하려고 하는 오류를 일으킬 수 있는 종류의 코드

편집 2
_some_ (잘못된/안전하지 않은) 코드를 깨뜨리지 않으면 이 주제와 관련하여 변경할 의미가 없습니다 .

그러나 다시 말하지만 이것은 단지 구문 문제이기 때문에 모든 것이 여전히 올바르게 컴파일되고 모든 곳에서 오류가 발생합니다.

_새로 입력하면 이전 코드가 손상되지만 어쨌든 발생합니다._

그렇지 않다. 예외적인 상황을 제외하고 우리는 기존 코드를 깨뜨리는 새로운 기능을 추가하지 않을 것입니다. 제네릭 및 공용체는 lib.d.ts 소비자가 새 버전의 컴파일러를 사용하기 위해 코드베이스를 업데이트해야 하는 방식으로 lib.d.ts에 추가되지 않았습니다. 예, 사람들은 이전 버전의 라이브러리를 사용하도록 선택할 수 있지만 기존 코드의 많은 부분을 손상시키는 언어 변경을 수행하려는 경우는 아닙니다(기본적으로 모든 주요 언어의 경우처럼). 이에 대한 예외가 가끔 있을 것입니다(https://github.com/Microsoft/TypeScript/wiki/Breaking-Changes). 그러나 그것들은 거의 없을 것입니다. 가장 자주 우리가 깨뜨리는 코드가 다음과 같이 될 수 있다고 믿는 경우 버그.

그러나 항상 프로젝트의 lib.d.ts를 고정하거나 이전 프로젝트를 가져올 수 있습니다.

lib.d.ts(및 BTW를 사용할 수 있는 다른 .d.ts)를 동결하는 것은 매우 강력한 의미를 갖습니다. 그것은 내가 사용하는 라이브러리나 새로운 HTML API에 대한 업데이트를 얻을 수 없다는 것을 의미합니다. 이것은 가볍게 생각할 일이 아닙니다.

이론적으로 이러한 기능을 사용하는 대부분의 코드는 어쨌든 보호되어야 합니다(일반적으로 큰 코드베이스에 있음). 보호하지 않으면 코드에 숨어 있는 버그가 있기 때문입니다.

JS는 다른 언어에서 오류를 발생시키는 많은 경우에 undefined (또는 때로는 null )를 반환하는 전통을 가지고 있습니다. 이것의 예는 Array.prototype.pop 입니다. C#에서 빈 스택에서 터지는 것은 던질 것입니다. 따라서 항상 유효한 값을 반환한다고 말할 수 있습니다. Javascript에서 빈 배열을 팝하면 undefined 반환합니다. 유형 시스템이 엄격하다면 어떻게든 처리해야 합니다.

나는 당신이 그것에 대해 대답할 것이라는 것을 알고 있었고, 이것이 내가 합법적이고 작동하는 코드 예제를 작성한 이유입니다. 대규모 코드 기반에서는 api가 일부 상황에서 null을 반환할 수 있는 많은 예를 찾을 수 있지만 특정 경우에는 안전하다는 것을 알고 있으므로 모든 안전 검사를 무시합니다.

나는 한 시간 전에 어떤 도서관의 마이크로 작업 부분을 보고 있었습니다. 주요 부분은 기본적으로 다음과 같습니다.

class MicroTasks {
  queue: Array<() => void>;

  flushQueue() {
    while (queue.length > 0) {
      let task = queue.pop();
      task();  // error possible null dereference (not!)
     }
  }
}

이런 경우가 많이 있습니다.

편집 2와 관련하여: 예, 이 변경이 버그를 잡아내고 유효하지 않은 코드를 지적하기를 _윌_합니다. 나는 그것이 유용하고 그것이 어떻게든 일어나기를 바라는 이유라고 확신합니다. 그러나 TS 팀은 _valid_ 코드의 주요 변경 사항을 고려할 것입니다. 여기서 결정해야 할 절충점이 있습니다.

@danquirk Fair 그렇다면 이 기능은 절대 구현될 수 없다고 생각합니다.
@jods4 무슨 말인지 이해하지만 해당 코드를 깨뜨리지 않고는 nullable을 구현할 수 없습니다.

슬프게도, 마침내 그 문제를 닫아야 합니까?

아마.

nullable 및 non-nullable 인수를 피한다면 ...

다음과 같은 일련의 새로운 기능을 사용하여 문제를 방해하지 않는 방식으로 해결(또는 완화)할 수 있습니다.

• null-typeguard 기호 소개 ?<type>
  유형에 이 기호로 주석이 달린 경우 직접 액세스하는 것은 오류입니다.

``` 타입스크립트
var foo: ?문자열;

foo.indexOf('s'); // 오류
foo && foo.indexOf('); // 괜찮아
```

• 깃발 소개 --nouseofunassignedlocalvar

``` 타입스크립트
var foo: 문자열;

foo.indexOf('s'); // 오류

foo = '바';

foo.indexOf('s'); // 괜찮아
```

흥미로운 역사적 메모 : 이에 대한 관련 문제를 찾으려고 하는 동안 2013년 2월에 --cflowu 컴파일러 옵션을 언급하는 codeplex의 오래된 문제 를 발견했습니다. @RyanCavanaugh , 그 깃발에 무슨 일이 일어났는지 궁금합니다.

• 안전운항 오퍼레이터 #16을 소개합니다.

TypeScript var x = { y: { z: null, q: undefined } }; console.log(x?.y?.z?.foo); // Should print 'null'

이러한 기능을 결합하면 실제로 모든 사람에게 신경 쇠약을 일으키지 않으면서 null 사용과 관련된 더 많은 오류를 포착하는 데 도움이 됩니다.

@NoelAbrahams :
당신의 첫 번째 제안은 본질적으로 나의 마지막 제안과 완전히 동일합니다. 당신은 단지 ? |null 대신( lib.d.ts 업데이트 및 주요 변경 사항에 대한 문제에 대한

두 번째 제안에는 @RyanCavanaugh (위)가 이전에 해결한 문제가 있습니다.

언어의 의미를 바꾸는 플래그는 위험한 것입니다. 한 가지 문제는 효과가 잠재적으로 매우 비국소적이라는 것입니다.
...[한조각]...
할 수 있는 유일한 안전한 방법은 할당 가능성의 의미 체계를 동일하게 유지하고 현재 noImplicitAny가 작동하는 방식과 마찬가지로 플래그에 의존하지 않는 것과 오류가 있는 것을 변경하는 것입니다.

나는 유사하지 않은 플래그가 더 일찍 제안 되었고 @RyanCavanaugh 의 의견 때문에 포기

세 번째 제안은 현재 주제와 거의 관련이 없습니다(더 이상 입력 및 컴파일 시간 오류가 아니라 런타임 오류 포착). 내가 이렇게 말하는 이유는 이 주제가 생성된 이유는 새로운 null을 추가하지 않고 "안전한" 것으로 알려진 변수에 대해 정의되지 않았거나 null 검사를 수행할 필요성을 줄이는 데 도움이 되었기 때문입니다. 또는 정의되지 않은 검사가 도처에 있습니다.

제안된 제안 중 하나를 구현하고 nullable(및 다른 라이브러리)을 사용하도록 lib.d.ts를 업데이트하지 않을 수 있습니까? 그런 다음 커뮤니티는 원하는 경우 nullable이 있는 자체 버전을 유지/사용할 수 있습니까?

편집하다:
특히 모든 libs에는 최신 정보가 포함되어 있지만 typeguard가 필요하도록 업데이트된 형식은 없습니다.

@RyanCavanaugh (특히 .d.ts 파일이 업데이트되지 않은 경우) 그다지 큰 변화가 아님을 보여주는 패치가 있는 경우 다시 와서 논의하겠습니다.

@danquirk 유형 정의는 업데이트할 필요가 없습니다. "잘못된" 상태로 남아 있을 수 있으며 대부분 이전 버전과 호환됩니다.

어쨌든 이 문제는 잃어버린 원인인 것 같습니다.

그건 그렇고, 무엇보다도 이 작업을 수행하는 MSR의 수정된 컴파일러가 있었습니다. 해당 결과와 함께 사용할 수 있는 문서가 있습니까? 편집: 찾았습니다: http://research.microsoft.com/apps/pubs/?id=224900 하지만 불행히도 관련이 확실하지 않습니다.

@Griffork , 네, 거의 모든 것이 토론의 길이를 감안할 때 어떤 형태로든 논의되었다고 확신합니다. 내 요약은 여러 관련 기능을 도입하여 null과 관련된 문제를 완화하는 방법에 대한 실용적인 것입니다.

모든 곳에서 새로운 null 또는 정의되지 않은 검사를 추가하지 않음

할당되지 않은 지역 변수를 트래핑하면 이를 완화하고 안전 탐색 연산자는 제안된 ES 기능이므로 어느 시점에서 TS에 도착합니다.

나는 또한 이것이 TS에 들어갈 확률이 낮다고 생각합니다 ... :(

내가 생각할 수 있는 유일한 해결책은 null 안전을 옵트인 컴파일러 플래그로 만드는 것입니다. 예를 들어 새로운 T | null 또는 ?T 구문을 도입하지만 프로젝트가 옵트인하지 않는 한 _any_ 오류를 발생시키지 마십시오. 따라서 새 프로젝트는 이점을 얻고 코드를 새 기능과 호환되도록 선택한 이전 프로젝트도 혜택을 받습니다. 너무 커서 쉽게 적응할 수 없는 큰 코드베이스는 이 기능을 사용할 수 없습니다.

그렇다고 해도 이 기능을 구현하기 위해서는 몇 가지 문제가 남아 있습니다...

@NoelAbrahams 죄송합니다. 제 요점은 그것이 나쁜 제안이 아니라 이 토론의 선동에서 원하는 답변이 아니라는 것입니다.
나는 그것이 네이티브가 될 때(/if) 그 기능을 사용할 것이라고 확신합니다. 정말 좋은 소리가 납니다.

위에서 인용한 @RyanCavanaugh 주석과 동일한 문제가 있는 @jods4 (플래그가 변경될 때 다른 곳에서 문제로 인한 할당 오류).

다시 말하지만, 가장 쉬운 방법은 다른 제안 중 하나(아마도 @spion 's)를 구현하고 .d.ts'에 새 유형을 추가하지 않는 것입니다.

@그리포크
이것은 "몇 가지 문제" 중 하나가 남아 있지만 반드시 그런 것은 아닙니다. 플래그를 활성화해도 프로그램 의미가 변경되지 _않도록_ 기능을 설계해야 합니다. 오류만 발생시켜야 합니다.

예를 들어 'not null' !T 디자인을 사용하는 경우 이 문제가 없다고 생각합니다. 그러나 이것은 해결 문제와는 거리가 멉니다.

또한 T | null 는 주요 변경 사항인 반면 ?T 는 그렇지 않다는 점을 지적해야 합니다.

@jods4 저는 "의미론 변경"에 "할당 능력 변경"이 포함되어 있다는 인상을 받았습니다. 어느 쪽이든 (그리고 아마도 @RyanCavanaugh 의) 비-로컬 효과에 대한 우려는 여전히 유효합니다.

@NoelAbrahams 어떻게?
티 | null은 typeguard가 필요하고 ?T는 typeguard가 필요하며 이름/기호가 다른 동일한 것입니다.
예, 플래그를 사용하여 둘 다 "켜짐"으로 설정할 수 있습니다.
차이를 못느끼나요?

@Griffork , 내가 보기에 ?T 단순히 "null을 확인하지 않고 액세스하지 마십시오"를 의미합니다. 검사를 시행하기 위해 이 주석을 새 코드에 자유롭게 추가할 수 있습니다. 나는 이것을 유형 주석이 아닌 일종의 연산자로 생각하고 있습니다.

T|null 주석은 기본적으로 유형이 nullable인지 여부에 대한 설명을 작성하기 때문에 기존 코드를 중단합니다.

@jbondc
흥미롭네요... 아직 당신의 제안에 대해 깊이 생각하지 않았지만 그럴 것 같습니다.

현재 컴파일러가 적용하는 불변성은 JS에서 스레딩 모델이 공유 데이터를 금지하기 때문에 다른 언어에서만큼 흥미롭지 않습니다. 그러나 분명히 명심해야 할 것이 있습니다.

@NoelAbrahams
모든 null 시행 제안은 변경 사항을 깨고 있습니다. 당신이 설명한 ?T . 위의 몇 가지 의견이 왜 그런지 몇 가지 예를 보여주었습니다.

이것이 우리가 이것을 원하는 경우 유일한 방법은 컴파일러 옵션으로 만들고 옵션을 활성화하면 보고된 오류는 변경되지만 프로그램 동작은 변경되지 않도록 충분히 고려하는 것이라고 생각하는 이유입니다. 가능한지 여부는 확실하지 않습니다.

저는 사실 이게 좀 괜찮습니다. TS 1.5를 사용하면 원하는 것을 얻을 수 있습니다.

function isVoid(item:any): item is void { return item == null; }
declare externalUnsafeFunction(...):string|void

function test() {
  var res = externalUnsafeFunction(...);
  var words = res.split(' '); // error
  if (!isVoid(res)) {
    var words = res.split(' '); // ok
  }
}

이제 externalUnsafeFunction 또는 반환 유형에 |void 를 추가하는 다른 함수 또는 함수 정의의 반환 값에 대해 isVoid 검사가 강제 실행됩니다.

나는 여전히 null/undefined를 허용하지 않는 함수를 선언할 수 없지만 지역 변수와 클래스 멤버를 초기화하는 것을 기억할 만큼 부지런할 수 있습니다.

@NoelAbrahams 때문에 null 유형이 있더라도 미래의 컴파일러 플래그가 변경하지 않는 한 null이 다른 유형으로 암시적으로 캐스트되도록 허용해야 한다고 이미 논의했습니다.

또한 그것은 미래에 우리 가 언제 어디서 함수가 null을 받아들일 수 있는지 주석을 달도록 하는 컴파일러 플래그를 가져올

그리고 개인적으로 나는 우리가 단어를 대신 사용할 수 있을 때 유형을 나타내기 위해 기호를 사용하는 아이디어를 싫어합니다.

@spion 실제로 좋은 지적입니다. 그것이 현재 TS에서 작동한다면 틀림없이 모든 내장 d.ts 파일이 이미 "잘못" 되어 있으며 제안한 수정 사항으로 제안한 null 유형을 추가해도 아무 것도 변경되지 않습니다.

사실 이미 어느 정도 달성할 수 있기 때문에 이번 주에 그것을 사용하기 시작하자고 상사에게 제안할 것입니다.

나는 우리가 T|void 를 미래에 깨는 것을 두려워하는 구문으로 보지 않는다는 점에 주의할 것입니다. 거의 넌센스입니다.

@RyanCavanaugh void === undefined(할당 가능한 값)만큼 넌센스입니다.

한숨을 쉬다.

코드가 너무 커서 T|void 에 따라 시작하기에는 너무 커서 곧 중단되고 교체되지 않을 것입니다. 그리고 나는 그것이 고장날 수 있다면 다른 프로그래머들에게 그것을 사용하도록 설득할 수 없을 것입니다.

좋아, @spion 이 패치를 만들면 알려주시면 내 작업의 코드베이스에 대해 실행하겠습니다. 나는 적어도 얼마나 많은 오류가 발생하는지에 대한 통계를 제공할 수 있습니다.

@RyanCavanaugh 넌센스, 정말? 어떤 방식으로? 그리고 null/undefined 검사 전에 모든 종류의 소비에 대해 금지되어야 하는 nullable 유형을 표현하기 위해 무엇을 제안하시겠습니까?

나는 그로부터 혜택을 받을 수 있는 많은 라이브러리를 가지고 있습니다.

@Griffork 어쨌든 1.5 이전에는 Union에서 void 를 안전하게 제거할 수 없으며 사용자 정의 유형 가드가 없으면 이것을 사용하는 것이 1.5 이후에만 가능합니다(가능한 경우).

이 코드를 작성하시겠습니까?

var foo: void;
var bar: void = doStuff();

당연히 아니지. 그렇다면 가능한 유형의 합집합에 void 를 추가하는 것은 무엇을 의미합니까? The Void Type (3.2.4)를 설명하는 섹션에서 꽤 오랫동안 존재했던 언어 사양의 이 부분을 주목하세요.

_참고: 유용한 목적을 제공하지 않는 Void 유형의 선언 변수를 허용하지 않는 것을 고려할 수 있습니다. 그러나 Void는 제네릭 형식이나 함수에 대한 형식 인수로 허용되기 때문에 Void 속성이나 매개 변수를 허용하지 않는 것이 가능하지 않습니다._

이 질문:

_그리고 null/undefined 검사 전에 모든 종류의 소비에 대해 금지되어야 하는 nullable 형식을 표현하려면 무엇을 제안하시겠습니까?_

전체 스레드에 대한 것입니다. Ryan은 현재 언어 의미론에 따르면 string|void 이 넌센스라는 것을 지적하고 있으므로 넌센스 의미론에 의존하는 것이 반드시 합리적이지는 않습니다.

위에서 작성한 코드는 afaik 완벽하게 유효한 TS 1.5입니다. 맞나요?

나는 확실히 넌센스가 아닌 예를 들겠습니다. 우리는 get() 라고 부르는 Linq의 Single()과 유사한 (nodejs) 데이터베이스 라이브러리 함수를 가지고 있습니다. 이 함수는 불행히도 항목을 찾을 수 없을 때 오류(거부된 약속)를 던지는 대신 Promise<null> 를 반환합니다. 수천 곳의 코드베이스 전체에서 사용되며 곧 대체되거나 사라질 것 같지 않습니다. 나와 다른 개발자가 값을 사용하기 전에 형식 보호를 사용하도록 하는 형식 정의를 작성하고 싶습니다. 잘못 사용되기 전에 코드베이스로 멀리 이동하는 null 값으로 인해 발생하는 수십 개의 추적하기 힘든 버그가 있기 때문입니다.

interface Legacy { 
  get<T>(...):Promise<T|void>
}

function isVoid(val: any): val is void { return val == null; } // also captures undefined

legacy.get(...).then(val => {
  // val.consumeNormally() is a type error here
  if (!isVoid(val)) { 
    val.consumeNormally(); // OK
  }
  else { handle null case }
});

이것은 나에게 완전히 합리적으로 보입니다. 추가 void 조합하려면 모든 작업됩니다 val 그들이해야로서, 무효. typeguard는 |void 를 제거하여 유형을 좁히고 T 부분을 ​​남깁니다.

아마도 사양은 void가 있는 공용체의 의미를 고려하지 않습니까?

void 변수를 허용하지 마십시오! 단위 유형 값으로 작동하며 사용할 수 있습니다.
표현식에서(모든 것의 2세트가 필요한 C#의 void와 달리: 하나
작업 및 하나의 기능에 대해). 빈칸으로 놔두세요, 알았죠?
2015년 1월 27일 오후 8시 54분에 "Gorgi Kosev" [email protected]이 다음과 같이 썼습니다.

위에서 작성한 코드는 afaik 완벽하게 유효한 TS 1.5입니다. 맞나요?

나는 확실히 넌센스가 아닌 예를 들겠습니다. 우리는
불행히도 Linq의 Single()과 유사한 데이터베이스 라이브러리 함수
반환 약속대신 오류(거부된 약속)가 발생합니다.
항목을 찾을 수 없습니다. 수천 개의 코드베이스에서 사용됩니다.
교체되거나 곧 사라질 것 같지 않습니다. 나는 쓰고 싶다
나와 다른 개발자가 유형 가드를 사용하도록 강제하는 유형 정의
값을 사용하기 전에 추적하기 어려운 수십 가지 버그가 있었기 때문에
이전에 코드베이스로 멀리 이동하는 null 값에서 비롯됩니다.
잘못 소비되었습니다.

인터페이스 레거시 {
가져 오기(...):약속하다
}
function isVoid(val: any): val is void { return val == null; } // 정의되지 않은 것도 캡처합니다.

legacy.get(...).then(발 => {
// val.consumeNormally()는 오류입니다.
if (!isVoid(val)) {
val.consumeNormally(); // 확인
}
else { null 케이스 처리 }
});

이것은 나에게 완전히 합리적으로 보입니다. 어떤 부분인지 지적해주실 수 있나요?
무의미한 말?

이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/Microsoft/TypeScript/issues/185#issuecomment -71767358
.

내가 말하는 것은 T|void 가 본질적으로 의미가 없다는 것입니다. 왜냐하면 우리는 이미 유형과 그 하위 유형의 합집합이 단순히 상위 유형과 동일하다는 규칙을 가지고 있기 때문입니다. 예를 들어 Cat|Animal 는 다음과 같습니다. Animal . void 를 null / undefined 값에 대한 대용으로 취급하는 것은 일관성이 없습니다. null 및 undefined 이 T 도메인 _ 모든 T , 이는 T 하위 유형이어야 함을 의미합니다.

즉, T|null|undefined , 작성할 수 있다면 이미 T 로 축소될 수 있습니다. void 를 null|undefined 대한 주문으로 취급하는 것은 잘못된 것입니다. 실제로 그랬다면 컴파일러는 T|void 를 이미 T 로 축소했을 것이기 때문입니다.

나는 개인적으로 이것을 읽을 것입니다 http://www.typescriptlang.org/Content/TypeScript%20Language%20Specification.pdf

Void 유형에 대해 가능한 유일한 값은 null 및 undefined입니다. Void 유형은 Any 유형의 하위 유형이고 Null 및 Undefined 유형의 상위 유형이지만 그렇지 않으면 Void는 다른 모든 유형과 관련이 없습니다.

처럼; T|void 에서 T 는 특히 void 의 상위 유형이 _아닙니다_ (사양에 따라) 유일한 상위 유형은 any 입니다.

편집 : 그것을 허용하지 않는 것은 다른 문제입니다.

Edit2: 당신이 말한 것을 다시 읽으십시오. 그리고 그것은 문자 그대로(문서에 void라는 단어가 있는 방식으로) 의미가 있지만 문서의 일반적인(또는 올바른) 해석으로 가정되는 것에서는 의미가 없습니다.

@RyanCavanaugh 나는 기능이 중단될 때까지 이 기능을 사용할 것입니다. 그 동안에는 많은 버그를 찾는 데 도움이 될 것 같습니다.

그리고 T|null|undefined 를 T 로 축소하는 것은 "이치에 맞는" 반면 T|void 는 존재하지 않는다는 아이러니를 지적하지 않을 수 없습니다. (스펙에 대한 것은 알지만 여전히 ...)

@jbondc

ECMAScript에는 정적 구조 유형이 없으므로 해당 인수가 유효하지 않습니다. ECMAScript에서 모든 값은 any 유형이므로 무엇이든 할당하거나 전달할 수 있습니다. 그 사실은 JS에 존재하지 않는 것을 개선하기 위해 존재하는 TypeScript의 정적 유형 시스템에 대해 아무 것도 암시해서는 안 됩니다.

아이러니를 설명해야 한다는 것이 조금 슬프지만 다음과 같습니다.

1. 메서드와 속성을 지원하지 않는 값이 있습니다. null
2. 이 값을 모든 유형의 변수에 할당할 수 있는 유형 시스템을 만듭니다. 대부분은 다양한 메서드와 속성(예: 문자열 숫자 또는 복잡한 개체 var s:string = null )을 지원합니다.
3. 해당 값을 올바르게 수락하고 메서드나 속성을 허용하지 않는 void 유형을 만들고 결과적으로 T|void 메서드와 속성을 허용하지 않습니다.

주장은 (3)은 말도 안되는 반면 (2)는 그렇지 않다는 것입니다. 여기서 아이러니한 부분이 보이시나요? 그렇지 않은 경우 다른 예를 시도해 보겠습니다.

1. 일부 메서드와 속성만 지원하는 값이 있습니다. {}
2. 이 값이 훨씬 더 많은 메서드와 속성 집합을 가진 모든 유형의 변수(예: 문자열 숫자 또는 복잡한 개체 var s:string = {} )에 할당할 수 있는 유형 시스템을 만듭니다.
3. {} 값을 올바르게 수락하고 몇 가지 내장된 것 외에는 메서드나 속성을 허용하지 않는 {} 유형이 있으며 T|{} 당연히 다른 메서드나 속성을 허용하지 않습니다. {}

이제 (2)와 (3) 중 어느 것이 넌센스입니까?

두 예의 유일한 차이점은 무엇입니까? 몇 가지 내장 메서드.

마지막으로 인터페이스는 유형 정의 설명에 불과했습니다. 어디에서나 구현되는 인터페이스가 아닙니다. 라이브러리에서 제공하는 인터페이스로, 약속 이외의 것은 절대 반환하지 않지만 null에 대한 약속은 반환할 수 있습니다. 따라서 안전은 확실히 매우 현실적입니다.

@spion 그게 바로 내가 생각했던 것입니다.

여기에서 이것이 조금 정리될 것이라고 생각합니다.
사양 에 따르면:

무효란 무엇입니까?

void 키워드로 참조되는 Void 타입은 값이 없음을 나타내며, 리턴값이 없는 함수의 리턴타입으로 사용된다.

따라서 void는 null|undefined가 아닙니다.

Void 유형에 대해 가능한 유일한 값은 null 및 undefined입니다.

따라서 null 및 undefined는 void에 할당할 수 있습니다(다른 거의 모든 것에 할당할 수 있기 때문에).

Null은 유형입니다.

3.2.5 널 유형
Null 유형은 유사한 이름의 JavaScript 기본 유형에 해당하며 null 유형입니다.
정확한.
null 리터럴은 Null 유형의 유일한 값을 참조합니다. Null 형식 자체를 직접 참조하는 것은 불가능합니다.

정의되지 않은 유형입니다.

3.2.6 정의되지 않은 유형
정의되지 않은 유형은 유사한 이름의 JavaScript 기본 유형에 해당하며 정의되지 않은 리터럴의 유형입니다.

Void는 Null 및 Undefined _types_의 상위 유형일 뿐입니다.

. Void 유형은 Any 유형의 하위 유형이고 Null 및 Undefined 유형의 상위 유형이지만 그렇지 않으면 Void는 다른 모든 유형과 관련이 없습니다.

그래서 @jbondc 는 Typescript 언어 사양에 따라 null은 값, Null은 유형, undefined는 값, Undefined는 유형, Void(코드에서 소문자)는 Null의 상위 유형인 유형입니다. 정의되지 않았지만 다른 유형으로 _암시적으로 캐스트_하지 않습니다( any 제외). 사실, Void는 Null 및 Undefined 유형과 다른 동작을 하도록 특별히 작성되었습니다.

무효의:

Void 유형은 Any 유형의 하위 유형이고 Null 및 Undefined 유형의 상위 유형이지만 그렇지 않으면 Void는 다른 모든 유형과 관련이 없습니다.

없는:

Null 유형은 정의되지 않은 유형을 제외한 모든 유형의 하위 유형입니다. 즉, null은 Number 및 Boolean 기본 유형을 포함하여 모든 기본 유형, 객체 유형, 공용체 유형 및 유형 매개변수에 대해 유효한 값으로 간주됩니다.

찾으시는 주소가 없습니다:

정의되지 않은 유형은 모든 유형의 하위 유형입니다. 이는 undefined가 모든 기본 유형, 객체 유형, 공용체 유형 및 유형 매개변수에 대해 유효한 값으로 간주된다는 것을 의미합니다.

이제 더 명확해 졌습니까?

우리가 요구하는 것은 null에 대한 보호를 강제하는 유형과 undefined에 대한 보호를 강제하는 유형입니다. 다른 유형에 할당할 수 없도록 null 또는 undefined를 요청하는 것이 아니라(너무 중요한 작업) 추가 마크업을 선택하는 기능일 뿐입니다. 젠장, Null 또는 Undefined(유형)라고 부를 필요도 없습니다.

@jbondc 이것은 아이러니입니다. TS 컴파일러가 무엇을 말하든 JS의 null 및 정의되지 않은 값은 예외를 던지는 것 외에는 어떤 메서드나 속성도 지원하지 않습니다. 따라서 모든 유형에 할당할 수 있도록 하는 것은 의미가 없으며, {} 값을 문자열에 할당하도록 허용하는 것과 같은 의미입니다. TS의 void 유형에는 값이 포함되어 있지 않습니다. _하지만_ null 또는 undefined 는 모든 사람에게 할당할 수 있으므로 void 유형의 변수에 할당할 수 있으므로 여기에 또 다른 말도 안되는 부분이 있습니다. 그리고 그것이 아이러니입니다. (유형 가드와 공용체를 통해) 둘 다 현재 실제로 의미가 있는 것으로 결합됩니다. :)

TS 컴파일러만큼 복잡한 것이 가드 없이 작성되었다는 점은 생각해 볼 문제입니다.

PHP 또는 JAVA로 작성된 꽤 큰 응용 프로그램이 있으며 언어를 더 좋게 만들거나 더 나쁘게 만들지 않습니다.
이집트 피라미드는 현대 기계 없이 만들어졌습니다. 지난 4500년 동안 우리가 발명한 모든 것이 쓰레기라는 뜻입니까?

@jbondc null 및 정의되지 않은 값(목록의 첫 번째 값 빼기)으로 인한 TypeScript 컴파일러 의 문제 목록 과 함께 위의 내 설명을 참조하십시오.

@jbondc 세계의 문제를 해결하기 위한 것이 아니라 개발자가 마음대로 사용할 수 있는 또 다른 도구여야 합니다.
함수 오버로드, 공용체 및 유형 별칭과 동일한 영향과 유용성을 갖습니다.
개발자가 값을 보다 정확하게 입력할 수 있도록 하는 또 다른 옵트인 구문입니다.

유형을 nullable이 아닌 것으로 만드는 것에 대해 언급된 큰 문제 중 하나는 기존 TypeScript 코드에 대해 수행할 작업입니다. 여기에는 두 가지 문제가 있습니다. 1) nullable이 아닌 유형을 지원하는 최신 컴파일러와 기존 코드를 작동하도록 만들기 및 2) 업데이트되지 않은 코드와 상호 운용 - Python 2/3 스타일의 난관 방지

기존 TS 코드를 자동으로 다시 작성하여 빌드하도록 하는 도구를 제공하는 것이 가능해야 하며 이 제한된 경우에는 Python에서 2to3보다 훨씬 더 잘 작동하는 도구를 제공해야 합니다.

점진적 마이그레이션은 다음과 같이 보일 수 있습니다.

1. 널(null) 유형을 나타내기 위해 '?T' 구문에 대한 지원을 도입합니다. 처음에 이것은 유형 검사에 영향을 미치지 않으며 문서화를 위해 존재합니다.
2. '?T'를 사용하도록 기존 코드를 자동으로 다시 작성하는 도구를 제공합니다. 가장 멍청한 구현은 'T'의 모든 사용을 '?T'로 변환합니다. 더 똑똑한 구현은 유형을 사용하는 코드가 암시적으로 null이 아닌 것으로 가정하고 이 경우 'T'를 사용하는지 여부를 확인합니다. '?T' 유형의 값을 'T'를 예상하는 매개변수 또는 속성에 할당하려는 코드의 경우, 이는 값이 null이 아니라고 주장하는 자리 표시자로 값을 래핑할 수 있습니다(예: let foo: T = expect(possiblyNullFoo) 또는 let foo:T = possiblyNullFoo!
3. 제공된 모든 유형 정의와 확실히 유형이 지정된 저장소에 있는 유형 정의에 도구를 적용합니다.
4. 'T'를 예상하는 슬롯에 '?T'를 할당하려고 할 때 컴파일러 경고를 도입합니다.
5. 경고가 실행되도록 하고 이식이 관리 가능한지 확인하고 변경 사항이 수신되는 방식을 확인합니다.
6. 컴파일러의 주요 새 릴리스에서 'T' 오류가 예상되는 슬롯에 '?T'를 할당합니다.

아마도 도구가 아직 적용되지 않은 코드의 사용을 쉽게 하기 위해 특정 모듈에 대한 경고를 비활성화하는 것을 도입할 가치가 있을 수도 있습니다.

이전 의견에서 언어 분할을 피하기 위해 일반 'T'의 null 허용 여부를 선택하는 모드가 없으며 6단계가 실용적이지 않은 경우에도 1-3단계 자체가 유용할 것이라고 가정합니다.

내 임의의 생각:

1. expect() 부분은 복잡할 수 있으므로 잘 생각해야 합니다. 할당뿐만 아니라 인터페이스, 제네릭 또는 매개변수 유형...
2. 나는 _생각__ TS에는 경고가 없고 오류만 있습니다. 내가 옳다면 그 기능에 대해서만 경고를 표시할지 확신할 수 없습니다.
3. 많은 사람들이 코드를 업그레이드하더라도 기업은 업그레이드 속도가 매우 느리거나 기존 코드베이스가 큰 경우에는 업그레이드를 원하지 않을 수도 있습니다. 이로 인해 해당 주요 릴리스는 TS 팀이 원하지 않는 엄청난 변경 사항이 되었습니다.

즉, 여전히 null 오류를 보고하는 "선택" 플래그가 허용 가능한 솔루션이라고 생각합니다. 문제는 플래그가 꺼져 있을 때 동일한 코드/정의가 동일한 동작(오류 제외)을 가져야 한다는 것인데, 아직 생각할 시간이 없었습니다.

@jods4 - expect() 부분의 경우 ?T 가 있는 곳마다 컴파일러가 T | undefined 를 볼 수 있으므로 다음과 같이 공용체 유형을 처리하는 규칙을 재사용할 수 있습니다. 가능한.

TypeScript에서 '깃발의 날'이 얼마나 현실적인지 잘 모르겠습니다. '옵트인' 플래그 외에도 결국 옵트아웃 플래그가 되는 옵트인 플래그일 수도 있습니다. 관용구 스타일이 무엇인지에 대한 명확한 방향을 갖는 것이 중요합니다.

이 토론과 관련된 다른 것 - https://github.com/rwaldron/tc39-notes/blob/master/es6/2015-01/JSExperimentalDirections.pdf 유형 정보(TypeScript 스타일을 통해 지정됨) 사용에 대한 Chrome 팀의 조사에 대해 설명합니다. 주석)을 컴파일러에서 사용하여 JS를 최적화합니다. null 가능성에 대한 열린 질문이 있습니다. nullable이 아닌 유형을 원하지만 실행 가능성에 대해서도 확신하지 못합니다.

여기에서 다시 전화를 겁니다. 우리가 이 문제를 제대로 해결하지 못했다는 사실에 놀랐습니다.

여기에 부가 가치가 있다고 말합니다. 컴파일 타임에만 적용 가능한 것.
null 값을 확인하기 위해 더 많은 코드를 작성하는 대신 값을 nullable이 아닌 것으로 선언할 수 있으면 시간과 코딩을 절약할 수 있습니다. 유형을 'nullable이 아님'으로 설명하면 null이 아닌 것으로 예상되는 다른 함수에 전달되기 전에 초기화되어야 하고 null이 아닌 것으로 선언되어야 합니다.

위에서 말했듯이 코드 계약 구현으로 간단히 해결할 수 있습니다.

null 리터럴 사용을 중단하고 모든 장소를 보호할 수 없는 이유는 무엇입니까?
null이 코드에 누출될 수 있습니까? 이렇게하면 null로부터 안전합니다.
모든 곳에서 null 검사를 수행할 필요 없이 참조 예외.
2015년 2월 20일 오후 1시 41분에 "electricessence" [email protected]이 다음과 같이 썼습니다.

여기에서 다시 전화를 겁니다. 나는 우리가 정말로 해결하지 못했다는 것에 놀랐다
이 하나.

여기에 부가 가치가 있다고 말합니다. 컴파일시에만 적용되는 것
시각.
값을 null 확인하기 위해 더 많은 코드를 작성하는 대신 다음을 수행할 수 있습니다.
값을 nullable이 아닌 것으로 선언하면 시간과 코딩을 절약할 수 있습니다. 설명하자면
'nullable이 아님'으로 유형을 입력하면 초기화되어야 하고 가능하면 어설션되어야 합니다.
예상되는 다른 함수로 전달되기 전에 null이 아닌 것으로
null이 아닙니다.

위에서 말했듯이 코드 계약으로 간단히 해결할 수 있습니다.
구현.

이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/Microsoft/TypeScript/issues/185#issuecomment -75295204
.

Null 검사는 정의되지 않은 검사보다 훨씬 빠릅니다.
2015년 2월 21일 오전 11시 54분에 "Aleksey Bykov" [email protected]이 다음과 같이 썼습니다.

null 리터럴 사용을 중단하고 모든 장소를 보호할 수 없는 이유는 무엇입니까?
null이 코드에 누출될 수 있습니까? 이렇게하면 null로부터 안전합니다.
모든 곳에서 null 검사를 수행할 필요 없이 참조 예외.
2015년 2월 20일 오후 1시 41분 "electricessence" 알림 @github.com
썼다:

여기에서 다시 전화를 겁니다. 나는 우리가 정말로 해결하지 못했다는 것에 놀랐다
이 하나.

여기에 부가 가치가 있다고 말합니다. 컴파일시에만 적용되는 것
시각.
값을 null 확인하기 위해 더 많은 코드를 작성하는 대신 다음을 수행할 수 있습니다.
값을 nullable이 아닌 것으로 선언하면 시간과 코딩을 절약할 수 있습니다. 설명하자면
'non-nullable'로 입력하면 초기화되어야 하고 가능하면
주장
예상되는 다른 함수로 전달되기 전에 null이 아닌 것으로
null이 아닙니다.

위에서 말했듯이 코드 계약으로 간단히 해결할 수 있습니다.
구현.

이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
<
https://github.com/Microsoft/TypeScript/issues/185#issuecomment-75295204>
.

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/Microsoft/TypeScript/issues/185#issuecomment -75346198
.

내 요점은 이러한 검사가 필요하지 않다는 것입니다(null 키워드가 금지된 경우
그리고 그것이 들어올 수 있는 다른 모든 장소는 보호됩니다).

왜요? 1. 검사가 전혀 없는 코드는 코드보다 훨씬 빠르게 실행됩니다.
null 검사와 함께. 2. if가 적게 포함되어 더 읽기 쉽습니다.
유지 보수 가능.
2015년 2월 20일 오후 7시 57분에 "Griffork" [email protected]이 다음과 같이 썼습니다.

Null 검사는 정의되지 않은 검사보다 훨씬 빠릅니다.
2015년 2월 21일 오전 11시 54분에 "Aleksey Bykov" [email protected]이 다음과 같이 썼습니다.

null 리터럴 사용을 중단하고 모든 장소를 보호할 수 없는 이유는 무엇입니까?
null이 코드에 누출될 수 있습니까? 이렇게하면 null로부터 안전합니다.
모든 곳에서 null 검사를 수행할 필요 없이 참조 예외.
2015년 2월 20일 오후 1시 41분 "electricessence" 알림 @github.com
썼다:

여기에서 다시 전화를 겁니다. 나는 우리가 정말로 해결하지 못했다는 것에 놀랐다
이 하나.

여기에 부가 가치가 있다고 말합니다. 컴파일시에만 적용되는 것
시각.
null 값을 확인하기 위해 더 많은 코드를 작성하는 대신
에게
값을 nullable이 아닌 것으로 선언하면 시간과 코딩을 절약할 수 있습니다. 만약 내가
설명하다
'non-nullable'로 입력하면 초기화되어야 하고 가능하면
주장
예상되는 다른 함수로 전달되기 전에 null이 아닌 것으로
null이 아닙니다.

위에서 말했듯이 코드 계약으로 간단히 해결할 수 있습니다.
구현.

이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
<
https://github.com/Microsoft/TypeScript/issues/185#issuecomment -75295204

.

이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
<
https://github.com/Microsoft/TypeScript/issues/185#issuecomment-75346198>
.

이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/Microsoft/TypeScript/issues/185#issuecomment -75346390
.

요점을 놓치고 있습니다. 정의되지 않은 검사를 피하기 위해 null을 사용합니다.
그리고 우리의 애플리케이션은 하나의 일관된 상태를 가지고 있지 않기 때문에,
종종 객체 대신 null/undefined가 되어야 합니다.
그것을 나타냅니다.
2015년 2월 21일 오후 12시 20분에 "Aleksey Bykov" [email protected]이 다음과 같이 썼습니다.

내 요점은 이러한 검사가 필요하지 않다는 것입니다(null 키워드가 금지된 경우
그리고 그것이 들어올 수 있는 다른 모든 장소는 보호됩니다).

왜요? 1. 검사가 전혀 없는 코드는 코드보다 훨씬 빠르게 실행됩니다.
null 검사와 함께. 2. if가 적게 포함되어 더 읽기 쉽습니다.
유지 보수 가능.
2015년 2월 20일 오후 7시 57분에 "Griffork" [email protected]이 다음과 같이 썼습니다.

Null 검사는 정의되지 않은 검사보다 훨씬 빠릅니다.
2015년 2월 21일 오전 11시 54분, "Aleksey Bykov" 알림 @github.com
썼다:

null 리터럴 사용을 중단하고 모든 장소를 보호할 수 없는 이유는 무엇입니까?
어디
null이 코드에 누출될 수 있습니까? 이렇게하면 null로부터 안전합니다.
모든 곳에서 null 검사를 수행할 필요 없이 참조 예외.
2015년 2월 20일 오후 1시 41분 "electricessence" 알림 @github.com
썼다:

여기에서 다시 전화를 겁니다. 나는 우리가 정말로하지 않았다는 것에 놀랐다
해결
이 하나.

여기에 부가 가치가 있다고 말합니다. 에서만 적용되는 것
엮다
시각.
null 값을 확인하기 위해 더 많은 코드를 작성하는 대신
할 수있는
에게
값을 nullable이 아닌 것으로 선언하면 시간과 코딩을 절약할 수 있습니다. 만약 내가
설명하다
'non-nullable'로 입력하면 초기화되어야 하고 가능하면
주장
예상되는 다른 함수로 전달되기 전에 null이 아닌 것으로
null이 아닙니다.

위에서 말했듯이 아마도 이것은 단순히 코드로 해결할 수 있습니다.
계약
구현.

이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
<

https://github.com/Microsoft/TypeScript/issues/185#issuecomment -75295204

.

이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
<
https://github.com/Microsoft/TypeScript/issues/185#issuecomment -75346198

.

이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
<
https://github.com/Microsoft/TypeScript/issues/185#issuecomment-75346390>
.

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/Microsoft/TypeScript/issues/185#issuecomment -75347832
.

당신도 내 포인트를 놓치고 있습니다. 상태를 일관되게 유지하고 누락된 값을 나타낼 수 있도록 null 또는 undefined를 사용할 필요가 없습니다. 특히 이제 통합 유형 지원이 고려되는 다른 방법이 있습니다.

class Nothing { public 'i am nothing': Nothing; }
class Something { 
    constructor(
    public name: string,
    public value: number
   ) { }
}
var nothing = new Nothing();
var whoami = Math.random() > 0.5 ? new Something('meh', 66) : nothing;

if (whoami instanceof Nothing) {
    console.log('i am a null killer');
} else if (whoami instanceof Something) {
    console.log(whoami.name + ': ' + whoami.value);
}

그래서 우리는 null 또는 undefined를 사용하지 않고 누락된 값을 인코딩했습니다. 또한 우리는 100% 명시적인 방식으로 이를 수행하고 있습니다. 타입 가드 덕분에 값을 읽기 전에 체크를 놓칠 일이 없습니다.

얼마나 멋진가요?

검사 인스턴스가 null 검사보다 빠르다고 생각하십니까?
초당 수백 개의 작업을 수행해야 하는 애플리케이션?
다음과 같이 표현하겠습니다. 우리는 함수에 대한 별칭을 만들어야 했습니다.
'.'를 사용하지 않는 것이 더 빠릅니다. 접근자.
2015년 2월 21일 오후 12시 58분에 "Aleksey Bykov" [email protected]이 다음과 같이 썼습니다.

당신도 내 포인트를 놓치고 있습니다. 상태를 일관되게 유지하고
null을 사용할 필요가 없는 누락된 값을 나타낼 수 있거나
찾으시는 주소가 없습니다. 특히 이제 Union 유형이 지원되는 다른 방법이 있습니다.
고려하다:

class Nothing { public '나는 아무것도 아니다': 아무것도; }
클래스 뭔가 {
건설자(
공개 이름: 문자열,
공개 가치: 숫자
) { }
}
var 아무것도 = 새로운 아무것도();
var whoami = Math.random() > 0.5 ? 새로운 무언가('meh', 66) : 아무것도;

if (whoami instanceof 아무것도) {
// whoami는 아무것도 아니다
console.log('나는 널 킬러다');
} else if (whoami instanceof Something) {
// whoami는 Something의 인스턴스입니다.
console.log(whoami.name + ': ' + whoami.value);
}

그래서 null 또는 undefined를 사용하지 않고 누락된 값을 인코딩했습니다.
또한 우리는 _100% 명시적인 방식_으로 이를 수행하고 있습니다. 유형 감사합니다
경비원, 값을 읽기 전에 검사를 놓칠 수 있는 방법은 없습니다.

얼마나 멋진가요?

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/Microsoft/TypeScript/issues/185#issuecomment -75349967
.

@aleksey-bykov 이미 그 점을 언급했다는 점에 유의하십시오. 이미 null 값을 사용하는 기존 라이브러리에 대한 유형 정의를 모델링해야 하는 필요성은 해결되지 않았습니다. 이 경우 null 값을 "사용 중지"할 수 없습니다.

또한 undefined 가 될 초기화되지 않은 변수 문제는 다루지 않습니다. Haskell에서는 값을 "초기화되지 않은" 상태로 둘 수 없기 때문에 문제가 존재하지도 않습니다.

@Griffork , 나는 테스트를 실행하지 않는다고 생각합니다. 테스트에 따르면 브라우저에 따라 다릅니다.
http://jsperf.com/nullable-vs-null-vs-undefined-vs-instanceof
그래도 안전과 성능 사이에서 균형을 찾아야 한다고 생각합니다. 그런 다음 최적화를 시도하기 전에 성능을 주의 깊게 측정해야 합니다. 고장나지 않은 것을 수정하고 있을 가능성이 있으며 그렇게 우려하는 null 검사가 전체 성능의 2% 미만을 구성할 수 있습니다. 그렇다면 두 배 더 빠르게 만들면 1%만 얻을 수 있습니다.

@spion , 현재 상황과 non-nullable이 가져오는 문제를 감안할 때 코드에서 null을 계속 사용하는 것보다 훨씬 더 좋은 방법이라고 생각하는 모든 것

우리의 코드 베이스는 800개가 넘는 TypeScript 파일과 120,000줄 이상의 코드입니다.
그리고 비즈니스 모델링과 관련하여 null 또는 undefined가 필요하지 않았습니다.
도메인 엔터티. 그리고 DOM 조작을 위해 null을 사용해야 했지만,
이러한 모든 장소는 신중하게 격리되어 null이 누출되지 않습니다.
나는 null이 필요할 수 있다는 당신의 주장을 믿지 않습니다.
null이 전혀 없는(Haskell) 또는 null이 있는 프로덕션 준비 언어
금지됨(F#).
2015년 2월 22일 오전 9시 31분에 "Jon" [email protected]이 작성했습니다.

@aleksey-bykov https://github.com/aleksey-bykov 실용적인
관점에서 null을 무시할 수 없습니다. 다음은 귀하가
어쨌든 nullable 유형이 필요합니다.
https://www.google.com/patents/US7627594?ei=P4XoVPCaEIzjsATm4YGoBQ&ved=0CFsQ6AEwCTge

이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/Microsoft/TypeScript/issues/185#issuecomment -75437927
.

네, 그리고 여기에서 이해할 수 있는 가장 중요한 것은 우리가 비즈니스 도메인 엔터티를 모델링하지 않고 시간에 매우 민감하며 코드베이스가 귀하보다 너무 작지 않다는 것입니다.

목적을 위해 null이 필요하지 않습니다. 괜찮습니다. Null 없이 Typescript를 계속 사용할 수 있습니다.
우리의 목적을 위해서는 null이 필요하고, 그럴 여유가 없습니다.

아, 방금 다른 댓글을 봤습니다. 죄송합니다.
이 스레드의 앞부분을 읽으면 우리가 항상 null을 사용하고 다른 코드 비트에 스며드는 문제가 거의 발생하지 않았다고 (본질적으로) 말했음을 알 수 있습니다.

위에서도 읽었다면 nullable이 아닌 제안은 undefined도 포함합니다.

속도에 대한 변수에서 null과 undefined는 비슷해 보이지만 개체(특히 프로토타입 체인이 있는 개체)에 표시되는 즉시 이야기가 매우 다르기 때문에 대신 null을 사용합니다.

다시 말하지만 (저희처럼) <10ms 동안 10,000번의 검사를 수행하지 않는 한 걱정할 가치가 없습니다.

(그리고 예, 우리는 애플리케이션의 성능을 추적하고 병목 현상을 찾아 실제로 변경했습니다)

이에 대한 논의에 박차를 가하고 싶습니다. 어제 빌드 비디오 에서 C#으로 구현된 분석기를 보았습니다. TypeScript와 유사한 구현을 위해 이슈 #3003을 열었습니다.

기본적으로 분석기는 추가 구문 검사, 오류/경고로 태그 라인을 수행할 수 있고 언어 서비스에서 해석할 수 있는 라이브러리입니다. 이렇게 하면 외부 라이브러리와 null 검사를 효과적으로 시행할 수 있습니다.

사실 TypeScript의 분석기는 다른 용도로도 정말 훌륭할 것이라고 생각합니다. 거기에는 C#보다 훨씬 더 이상한 라이브러리가 있습니다.

이 문제를 따르는 모든 사람을 위해: 저는 변수의 null 허용 여부를 선언할 수 있는 monapt 라는 라이브러리를 유지 관리하고 있습니다. 여기에는 Typescript 정의가 포함되어 있으므로 모든 것이 컴파일 시간에 확인됩니다.

피드백 환영합니다!

방금 전체 스레드를 읽었습니다.

TS 사양의 void 가 null 및 undefined 값에 대한 유형이기 때문에 제안서는 non-voidable 및 voidable 용어를 사용해야 한다고 생각합니다 void . (제안은 정의되지 않은 값도 포함한다고 가정합니다 :smile: )

나는 또한 정의되지 않은 액세스 또는 null 예외가 프로그래밍에서 모든 악의 근원이라는 데 동의합니다. 이 기능을 추가하면 사람들의 수많은 시간을 절약할 수 있습니다.

이것을 추가해주세요! 그리고 이것이 기능이 된다면 플래그를 전달하여 기본값으로 만들 수 있다면 가장 좋을 것입니다. 그것은 많은 사람들에게 많은 디버깅 지옥을 절약할 것입니다.

ADT를 nullable 형식 대신 사용할 수 있다는 점에는 동의할 수 있습니다. 우리가 전달하는 ADT가 null이 아니라는 것을 어떻게 확신할 수 있습니까? ADT를 포함하여 TS의 모든 유형은 null이 될 수 있습니다. 맞습니까? 나는 이것이 ADT를 nullable이 아닌(non-voidable) 유형의 문제에 대한 솔루션으로 생각하는 데 있어 주요 결함이라고 봅니다. ADT는 nullable이 아닌 유형을 허용(또는 금지)하는 언어에서만 제대로 작동합니다.

또 다른 주요 문제는 라이브러리 정의입니다. 문자열을 인수로 예상하는 라이브러리가 있을 수 있지만 TS 컴파일러는 함수에 null 를 전달하는 검사를 입력할 수 있습니다! 옳지 않다...

ADT를 문제에 대한 해결책으로 생각하는 데 큰 결함이 있다고 봅니다...

1. 디자인 패턴을 통해 ADT를 사용할 수 있습니다(네이티브
   TypeScript에서 지원)
2. null 키워드 금지
3. null이 외부에서 코드로 누출될 수 있는 모든 장소를 보호하십시오.
4. null 문제가 영원히 사라짐을 즐기십시오

우리 프로젝트에서 우리는 1, 2, 3단계를 수행했습니다. 우리가 무엇을 하고 있는지 맞춰보세요
지금.

@aleksey-bykov

undefined (2) 어떻게 합니까? undefined 키워드가 포함되지 않은 다양한 상황에서 발생할 수 있습니다. 초기화되지 않은 클래스 멤버, 선택적 필드, 조건부 분기의 반환 문 누락...

typescript 와 flowtype을 비교하십시오. 적어도 흐름은 대부분의 경우를 다룹니다.

또한 "그 언어의 일반적인 관용구는 잊어버리세요. 상관없어요. 나머지 세계와 제 자신을 격리하겠습니다"라고 말하고 싶다면 아마도

정의되지 않은 키워드가 포함되지 않은 다양한 상황에서 발생할 수 있습니다.

• 초기화되지 않은 클래스 멤버 - 금지된 클래스
• 선택적 필드 - 선택적 필드/매개변수 금지
• 누락된 return 문 - 모든 실행 경로가 반환되도록 하는 사용자 지정 tslint 규칙

순수 스크립트를 사용하는 것이 좋습니다

• 나는 그것을 원하지만 그것이 생성하는 코드는 성능과 가장 관련이 있습니다.

@aleksey-bykov null 허용 유형을 ADT로 교체하면 흐름 유형과 같은 null 검사를 시행하는 것과 비교하여 상당한 CPU 및 메모리 오버헤드를 부과하기 때문에 성능을 언급하는 것이 재미있습니다. 클래스를 사용하지 않는 경우에도 마찬가지입니다(많은 메서드가 포함된 많은 개체를 인스턴스화하는 경우 엄청나게 비쌀 수 있음)

선택적 필드를 포기한다고 언급했지만 너무 많은 JS 라이브러리에서 사용하고 있습니다. 그 도서관들을 처리하기 위해 무엇을 했는가?

당신은 또한 클래스를 사용하지 않는다고 언급합니다. 나는 또한 클래스(예: React)에 의존하는(또는 의존할) 라이브러리를 피한다고 가정합니다.

어떤 경우에도 완벽하게 합리적인 솔루션(실제로 기본 유형이 지정되지 않은 언어에 맞는)이 구현될 가능성이 가장 높지만 많은 기능을 포기할 이유가 없습니다.

ADT의 유일한 목적이 그렇지 않으면 null로 인코딩되었을 누락된 값을 나타내는 것이라고 생각하는 것이 재미있습니다.

차라리 "null" 문제가 사라지는 것(클래스도 포함)이 ADT가 우리에게 가져다주는 모든 좋은 것들의 부산물이라고 말하고 싶습니다.

귀하의 호기심을 해결하기 위해, 타이트한 루프 및 대규모 데이터 구조와 같은 성능에 중요한 부분에 대해 TypeScript가 래핑된 값을 처리한다고 생각하도록 속여서 Nullable<a> 추상화를 사용하지만 실제로 (런타임에) 그러한 값은 단지 null을 허용하는 프리미티브에는 null이 누출되는 것을 방지하는 Nullable에 대한 특수 작업 세트가 있습니다.

세부 사항을 알고 싶다면 알려주세요

interface Nullable<a> {
    'a nullable': Nullable<a>;
    'uses a': a;
}
/*  the following `toNullable` function is just for illustration, we don't use it in our code,
    because there are no values capable of holding naked null roaming around,
    instead we just alter the definition of all unsafe external interfaces:
    // before
    interface Array<T> {
       find(callback: (value: T, index: number, array: T[]) => boolean, thisArg?: any): T;
    }
    // after
    interface Array<a> {
       find(callback: (value: a, index: number, array: a[]) => boolean, thisArg: any): Nullable<a>;
    }
*/
function toNullable<a>(value: a) : Nullable<a> {
    return <any>value;
}
function toValueOrDefault<a>(value: Nullable<a>, defaultValue: a)  : a {
    return value != null ? <any>value : defaultValue;
}

재귀 유형 구조를 사용하는 이유는 무엇입니까? 'a nullable': a 이면 충분하지 않습니까?

null을 반환하는 모든 외부 함수를 처리하기 위해 callFunctionWithNullableResult<T,U>(f: (T) => U, arg:T):Nullable<U> (arity가 다른 함수에 대한 다른 모든 오버로드 포함)도 있다고 가정합니다.

그리고 null 키워드가 linter에 의해 금지된 경우 nullable에 " Nothing "를 저장하는 방법은 무엇입니까? 특별한 경우 toNullable(null) 입니까?

대수 데이터 유형이 무엇인지 압니다. ADT(또는 오히려 합계 유형) + 패턴 일치가 typescript의 공용체 + 사용자 정의 유형 가드가 할 수 없는 일을 수행할 수 있는 인스턴스(완벽한 검사 및 투박함 제외)를 제공할 수 있습니까?

재귀 유형 구조를 사용하는 이유는 무엇입니까? 'nullable': 충분해야 합니다.

글쎄, 이 예에서는 그것으로 충분하지만, 이렇게 하면 2가지 별개의 경우를 제공하는 그러한 필드의 목적을 오버로드합니다.

• 유형을 명목으로 바꾸려면(귀하의 예에서 파일 이름): https://gist.github.com/aleksey-bykov/0ab85f0b5e83fc848f85
• 일반 유형 매개변수를 인식하도록 하여 개체의 표면까지 고려되도록 합니다(귀하의 예에서 값 유형): https://github.com/Microsoft/TypeScript/issues/468

나는 개인적으로 과부하가 걸리는 것을 싫어합니다. 이것이 내가 각각 별도의 문제를 해결하는 2개의 개별 의사 필드를 사용하는 이유입니다.

callFunctionWithNullableResult도 있다고 가정합니다.(f: T -> U, arg:T) => 널 입력 가능

아니요, 내가 말했듯이 우리는 외부 코드에서 null이 될 수 있는 증거가 있는 모든 것을 Nullable "wrapper"로 대체하여 정의(*.d.ts) 파일을 변경합니다. 주석의 예를 참조하십시오. 내 이전 메시지에서

nullable에 "아무것도 저장하지 않음"을 어떻게 얻습니까?

우리는 nullable에 null을 저장하지 않습니다. nullable은 서버(우리가 제한적으로 제어할 수 있음) 또는 외부 API에서 가져옵니다. 코드에 있는 즉시 Nullable로 래핑되지만 우리 코드는 다음을 생성할 수 없습니다. 임의의 nullable이 있는 경우 주어진 nullable을 다른 nullable로 변환할 수만 있지만 허공에서 생성할 수는 없습니다.

typescript의 공용체 + 사용자 정의 유형 가드는 할 수 없습니다.

하아! 나는 노조 유형의 팬이 아니며 그들을 나쁜 생각으로 만드는 것에 대해 몇 시간 동안 이야기 할 수 있습니다.

귀하의 질문으로 돌아가서 유니온 및 유형 가드를 사용하여 재사용 가능한 Either a b 를 제공하십시오.
(힌트: https://github.com/Microsoft/TypeScript/issues/2264)

귀하의 예에서 유형 은 재귀적이기 때문에 더 명목적이지 않습니다 . "의사 명목상"으로 유지됩니다.

그러나 귀하의 질문에 대답하기 위해: 유형이 명목상이 아니기 때문에 일반 중 하나를 구현하지 않습니다. 당신은 단순히 사용

type MyType = A | B

그런 다음 A 및 B 대해 유형 가드를 사용합니다. ... 보너스로 이것은 모든 기존 JS 라이브러리에서도 작동합니다. 예를 들어 Thenable 를 확인하는 관용적 방법은 다음과 같습니다. 개체에 연결된 then 메서드입니다. 유형 가드가 작동합니까? 거의 확실히.

하아! 그것은 당신의 빌어먹을 좋은 캐치입니다. 글쎄요, 컴파일러의 최신 버전에서 뭔가 변경되었을 것입니다. 방탄 명목은 다음과 같습니다.

enum GottaBeNonimalBrand {}
interface GottaBeNonimal {
     branded: GottaBeNonimalBrand;
}
function toGottaBeNominal() : GottaBeNominal {
   return <any> {};
}

잠시만 요! 당신은 속였다 ! 좋은 옛날 방식은 여전히 ​​매력처럼 작동합니다.

그러나 귀하의 질문에 대답하기 위해: 유형이 명목상이 아니기 때문에 일반 중 하나를 구현하지 않습니다. 당신은 단순히 사용 ...

좋은 말씀이네요 Either 어때요? 정통이 Either GENERIC하고 내가 할 수있는 모든 가능한 쌍에 대한 이러한 기능의 30 X number_of_combinations_of_any_2_types_in_my_app 많은 거기 약 30 표준 편의 기능을 이제 내가 (공칭) 해결 갈 필요가 말하는, 주위하고있다 맞닥 뜨리다?

이 스레드가 여전히 TS 팀의 사람들에 의해 모니터링되기를 바랍니다. 재부팅 해보고 싶어요!
non-null 유형이 깨지지 않는 방식으로 이것을 도입하는 것이 불가능하다는 것이 명백해졌을 때 막힌 것 같습니다. C# 팀은 nullable이 아닌 참조 형식에 대해 생각하고 있으며 물론 동일한 문제, 특히 호환성에 직면해 있습니다. 그들이 현재 탐구하고 있는 아이디어가 마음에 들고 TS에 적용할 수 있을지 궁금합니다.

C# vnext 브레인스토밍(간단히)

기본적으로 C#에는 int 와 같은 null이 아닌 값 유형이 있습니다. 그런 다음 C# 2.0에서 int? 와 같은 nullable 값 유형을 얻었습니다. 참조는 항상 null을 허용하지만 이를 변경하고 동일한 구문을 적용하는 방법을 생각하고 있습니다. string 는 null이 아니며 string? 는 null일 수 있습니다.

물론 큰 문제는 이것이 string 의 의미를 변경하고 코드를 중단한다는 것입니다. null 를 string 에 할당/반환해도 괜찮았지만 이제는 오류입니다. C# 팀은 사용자가 옵트인하지 않는 한 이러한 오류를 "비활성화"할 생각입니다. string? 찍는 것은 항상 오류입니다. 구문이 새롭고 이전에는 허용되지 않았기 때문입니다(따라서 주요 변경 사항이 아님).
다른 문제는 다른 라이브러리 등에 있습니다. 이를 해결하기 위해 파일 또는 어셈블리별로 옵트인 플래그를 만들려고 합니다. 따라서 더 엄격한 유형 시스템을 선택하는 외부 코드가 이점을 얻고 이전 레거시 코드와 라이브러리가 계속 작동합니다.

어떻게 TS로 바꿀 수 있습니까?

1. null이 아닌 유형의 옵트인 플래그를 도입합니다. 전역(컴파일러에 전달) 또는 파일 단위일 수 있습니다. .d.ts 대해서는 항상 파일별로 있어야 합니다.
2. 기본 유형은 nullable이 아닙니다(예: number . 새로운 null 유형이 있습니다.
3. number? 는 number | null 의 바로 가기입니다.
4. 이 기능은 유형 가드가 없는 (x: string?) => x.length 와 같이 nullable 유형에 대한 새로운 오류를 도입합니다.
5. 이 기능은 let x: string = null; 할당과 같은 nullable이 아닌 유형에 대한 새로운 오류를 도입합니다.
6. 옵트인 범위 외부에서 선언된 null이 아닌 유형을 조작할 때 5. 아래에 보고된 오류는 무시됩니다. _ string 가 여전히 string? 간주된다는 것과는 약간 다릅니다._

이게 무슨 소용이야?

새 코드를 작성할 때 내 코드와 업데이트된 라이브러리 정의에서 옵트인하고 완전한 정적 null 검사를 받을 수 있습니다. 오류 없이 레거시 라이브러리 정의를 계속 사용할 수 있습니다.

이전 코드를 사용할 때 새 파일을 선택할 수 있습니다. 어쨌든 string? 선언할 수 있으며 적절한 null 검사 없이 멤버에 액세스할 때 오류가 발생합니다. 또한 정의가 업데이트된 라이브러리에 대한 이점과 엄격한 검사를 받습니다. 한번 .d.ts 전달에 OPTS, null 정의하는 함수에 length(x: string): number 에러된다.
_(참고: string? 전달하는 것도 오류이지만 옵트아웃 코드에서 string 를 전달하는 것은 오류가 아닙니다.)_

선택하지 않는 한 주요 변경 사항은 없습니다.

어떻게 생각해?

물론 이 기능이 실제로 어떻게 작동할지에 대해 고려해야 할 사항이 많이 있습니다. 그러나 그러한 옵트인 방식이 TS 팀이 고려할 수 있는 것입니까?

사람들이 자동차 대신 더 빠른 말을 원하는 방법은 놀랍습니다.

겸손할 필요가 없습니다. ADT에 대한 귀하의 의견을 읽었지만 그것이 제게 필요한 것이 아니라고 생각합니다. 원하는 경우 "TS의 ADT 지원"에 대한 새로운 문제에서 논의할 수 있습니다. 왜 그것들이 좋은지, 왜 필요한지, nullable이 아닌 유형에 대한 필요성을 완화하는 방법을 쓸 수 있습니다. 이 문제는 nullable이 아닌 유형에 관한 것이며 실제로 주제를 가로채고 있습니다.

당신이 말하는 것은 상수 전파라고 하며 구현된 경우 null 및 undefined 된 2개의 임의 상수에 의해서만 제한되어서는 안 됩니다. 문자열, 숫자 및 기타 모든 것에 대해 동일한 작업을 수행할 수 있으며 이 방법은 의미가 있습니다. 그렇지 않으면 일부 사람들이 기꺼이 원하지 않는 몇 가지 오래된 습관을 기르기 위한 것입니다.

@aleksey-bykov 그리고 물론 더 나은 유형 제한을 얻으려면 더 높은 종류의 유형을 구현하고 파생된 인스턴스를 얻으려면 유형 클래스 등을 구현합니다. TypeScript의 "align with ES6+" 디자인 목표와 어떻게 일치합니까?

그리고 이 문제의 원래 문제를 해결하는 데 여전히 쓸모가 없습니다. 오늘날에도(공용체 유형 없이) 일반 클래스를 사용하여 TS에서 Maybe(또는 어느 쪽이든)를 쉽게 구현할 수 있습니다. Java에 Optional 를 추가하는 것만큼 유용할 것입니다. 누군가 null 어딘가에 할당하거나 선택적 속성이 필요하고 언어 자체는 불평하지 않지만 런타임에 상황이 폭발하기 때문입니다.

왜 당신이 언어를 남용하여 결코 의도하지 않은 방식으로 구부릴 수 있도록 주장하는지 나에게는 분명하지 않습니다. 대수 데이터 유형이 있고 null 값이 없는 기능적 언어를 원하면 PureScript를 사용하십시오. 일관성 있게 결합되는 기능을 갖춘 훌륭하고 잘 설계된 언어이며 Haskell의 축적된 사마귀 없이 Haskell에서 수년간 전투 테스트를 거쳤습니다(원칙적인 유형 클래스 계층 구조, 행 다형성이 있는 실제 레코드...). 내 생각에는 원칙과 요구 사항을 준수하는 언어로 시작한 다음 성능을 위해 조정하는 것이 훨씬 쉬운 것 같습니다. 당신의 방법을 작동합니다.

PureScript의 성능 문제는 무엇입니까? 퍼베이시브 커링에 의해 생성되는 폐쇄입니까?

@jods4 는 현재 존재하는 모든 .d.ts 파일이 out-of-work 플래그로 업데이트되어야 하거나 프로젝트 전체 설정이 .d.ts(및 .d.ts 플래그 없이는 항상 '오래된' 방식으로 간주됩니다.
이것은 얼마나 이해할 수 있습니까(.d.ts 파일을 읽을 때 여러 프로젝트에서 작업하는 사람들에게 문제를 일으키거나 혼란을 일으키나요?)?
새 코드와 이전(라이브러리) 코드 간의 인터페이스는 어떻게 생겼습니까? (경우에 따라) 불필요한 검사와 캐스트로 가득 차게 될까요?
대부분 나는 (현재) nullable이 아닌 유형에 대한 아이디어를 좋아하며 @jods4 및 ! Suggestion의 제안은 nullable이 아닌 유형이 작동하는 것을 볼 수 있는 유일한 방법입니다(adts 무시).

이 스레드에서 손실되었을 수 있지만 이것이 어떤 문제를 해결합니까? 그것은 나를 암시한 것입니다. 이 스레드에서 최근에 본 주장은 "다른 언어가 가지고 있습니다"입니다. 또한 TypeScript에서 일종의 기계 작업이 필요하지 않은 유용한 해결 방법을 확인하는 데 어려움을 겪고 있습니다. null 및 undefined 값이 바람직하지 않을 수 있다는 것을 이해할 수 있지만, 이를 기본 언어가 처리할 것으로 기대하는 대신 코드에 넣고 싶은 고차 논리로 보는 경향이 있습니다. .

다른 사소한 문제는 모든 사람이 undefined 를 상수 또는 키워드로 취급한다는 것입니다. 기술적으로도 그렇지 않습니다. 전역 컨텍스트에는 기본 유형 undefined 인 변수/속성 undefined 이 있습니다. null 는 리터럴입니다 ( typeof "object" 를 반환하도록 구현된 오랜 버그이긴 하지만 기본 유형 null 이기도 합니다). ECMAScript에서 이 두 가지는 상당히 다릅니다.

@kitsonk
문제는 모든 유형이 null일 수 있고 모든 유형이 정의되지 않을 수 있지만 특정 유형에서 작동하는 모든 작업이 null 또는 정의되지 않은 값(예: 나누기)에서 작동하지 않아 오류가 발생한다는 것입니다.
그들이 원하는 것은 유형을 "숫자이며 결코 null이거나 정의되지 않은" 것으로 지정하여 null 또는 정의되지 않은 프로그래머를 도입할 가능성이 있는 함수를 사용할 때 잘못된 값에 대해 보호할 수 있다는 것을 알도록 하는 것입니다.
값을 "이 유형이지만 null이거나 정의되지 않을 수 없음"으로 지정할 수 있는 두 가지 주요 인수는 다음과 같습니다.
A) 이 값이 null이거나 정의되지 않은 값이 아니어야 한다는 것은 코드를 사용하는 모든 프로그래머에게 명백합니다.
B) 컴파일러는 누락된 유형 가드를 잡는 데 도움이 됩니다.

정의되지 않은 기본 유형의 변수/속성이 정의되지 않았습니다. null은 리터럴입니다(기본 유형 null이기도 합니다.

@kitsonk 이것은 이 문제에 대한 훌륭한 논거입니다. null A가 아닌 number A, 그것은 더 이상 것 Person (A)보다 Car 없습니다. 그것은 고유한 유형이며 이 문제는 typescript가 이러한 구별을 할 수 있도록 하는 것입니다.

@kitsonk 가장 일반적인 오류 중 하나는 null 참조/액세스 정의되지 않은 오류라고 생각합니다. null/undefined가 아닌 속성이나 변수를 지정할 수 있는 기능을 사용하면 소프트웨어 코드가 더 확실해집니다. 또한 LS와 같은 도구를 사용하여 https://github.com/Microsoft/TypeScript/issues/3692 와 같은 버그를 잡을 수

설명해주셔서 감사합니다. 다시 살펴보니 여기에서도 뭔가 놓치고 있는 것 같습니다... TypeScript에 이미 "선택 사항" 인수가 있는데 다음이 제안으로 작동하지 않는 이유는 무엇입니까?

interface Mixed {
    optional?: string;
    notOptional: string;
    nonNullable!: string;
}

function mixed(notOptional: string, notNullable!: string, optional?: string): void {}

제안된 솔루션 중 일부에는 더 큰 기능이 있지만 이에 대한 유형 보호가 문제가 될 것이라고 생각합니다. (TypeScript의 내부 작동을 잘 모르지만) 이미 확인 중인 것의 확장처럼 보이기 때문입니다.

TypeScript에는 이미 "선택 사항" 인수가 있는데 다음이 제안으로 작동하지 않는 이유는 무엇입니까?

TS에서 지금 선택 사항을 명확히하기 위해 초기화하는 동안에만 선택 사항입니다. Null 및 undefined 는 여전히 모든 유형에 할당할 수 있습니다.

이것은 선택 사항의 직관적이지 않은 경우입니다.

interface A {
   a?: string;
}
let a: A = {} // ok as expected

interface B {
   b: string;
}
let b1: B = { b: undefined } //ok, but unintuitive
let b2: B = { b: null } // ok, but unintuitive
let b3: B = {} // error as expected

또는 TS에서 optional 를 단순하게 유지하려면 초기화할 수 없음을 의미합니다. 그러나 이 제안은 undefined 및 null을 무효화할 수 없는(null이 아닌, 정의되지 않은) 유형에 할당할 수 없다고 말합니다.

? 는 속성/인수 이름의 _존재_를 참조하거나 참조하지 않기 때문에 속성/인수 이름 옆에 배치됩니다. @tinganho 가 잘 설명했습니다. 그의 예를 확장:

function foo(arg: string, another?: string) {
  return arguments.length;
}

var a: A = {};
a.hasOwnProperty('a') // false
foo('yo') // 1, because the second argument is _non-existent_.
foo(null) // this is also ok, but unintuitive

null이 아닌 ! 는 이름의 _existence_와 관련이 없습니다. 유형과 관련이 있으므로 유형별로 배치해야 합니다. 형식은 null을 허용하지 않습니다.

interface C {
  c: !string;
}

let c1: C = { }; // error, as expected
let c2: C = { c: null }; // error, finally!
let c3: C = { c: 'str' }; // ok! :)

function bar(arg: !string) {
  return arg.length;
}

bar(null) // type error
bar('foo') // 3

@Griffork 기존 .d.ts 는 잘 작동하며 더 엄격한 정의를 지원하도록 원활하게 업데이트할 수 있습니다.
기본적으로 .d.ts 는 선택하지 않습니다. 라이브러리 작성자가 null이 아닌 충실한 정의로 라이브러리를 업데이트하는 경우 파일 상단에 플래그를 설정하여 이를 나타냅니다.
두 경우 모두 소비자의 생각/구성 없이 모든 것이 작동합니다.

@kitsonk 이것이 해결하는 문제는 버그를 줄이는 것입니다. 사람들이 null이 아닐 수도 있다고 가정하거나 null을 지원하지 않는 함수에 null을 전달하기 때문입니다. 많은 사람들과 함께 대규모 프로젝트에서 작업하는 경우 작성하지 않은 기능을 사용할 수 있습니다. 또는 잘 모르는 타사 라이브러리를 사용할 수도 있습니다. let x = array.sum(x => x.value) 하면 x 가 null이 아니라고 가정할 수 있습니까? 배열이 비어 있으면 0이 될 수 있습니까? 어떻게 아세요? 컬렉션에 x.value === null 가 허용됩니까? sum() 함수에서 지원합니까 아니면 오류가 될까요?
이 기능을 사용하면 이러한 경우가 정적으로 검사되고 지원하지 않는 함수에 null 가능성이 있는 값을 전달하거나 검사 없이 null 가능성이 있는 값을 소비하는 경우 오류로 보고됩니다.
기본적으로 완전한 형식의 프로그램에서는 더 이상 "NullReferenceException"이 있을 수 없습니다(불행하게도 undefined 관련 코너 케이스 제외).

선택적 매개변수에 대한 논의는 관련이 없습니다. null 허용 여부는 변수/매개변수 선언이 아니라 유형 시스템과 관련이 있으며 유형 가드, 공용체 및 교차 유형 등과 잘 통합됩니다.

_void_ 유형에는 값이 없지만 null 및 undefined 값을 모두 할당할 수 있습니다.

여기에 좋은 요약이 있습니다. https://github.com/Microsoft/TypeScript/issues/185#issuecomment -71942237

@jbondc 최근에 사양을 확인한 것 같아요. void 는 null 및 undefined 대한 포괄적인 용어입니다. void 0 에 대해 잘 모르지만 void 도 우산 아래에 있는 것 같습니다.

참조: https://github.com/Microsoft/TypeScript/blob/master/doc/spec.md#324 -the-void-type

any 추론합니다. 그러나 null 및 undefined 는 여전히 모든 유형에 할당할 수 있습니다.

void 0 항상 undefined 도 반환합니다 . http://stackoverflow.com/a/7452352/449132.

@jbondc 위에서 설명한 것과 같은 잠재적인 null 인식 유형 시스템에 대한 질문인 경우

function returnsNull() {
  return null;
}

null 유형을 유추해야 합니다.

undefined 주변에 많은 코너 케이스가 있으며 솔직히 말해서 저는 (아직?) 이 문제를 해결하는 가장 좋은 방법이 무엇인지 확신하지 못합니다. 그러나 그것에 대해 생각하는 데 많은 시간을 보내기 전에 TS 팀이 옵트인 전략에 대해 괜찮은지 알고 싶습니다.

마지막으로 이 토론에 참여했을 때 "우리는 주요 변경 사항을 적용하지 않을 것이며 주변 플래그/옵션을 기반으로 하는 소스 코드의 의미를 변경하고 싶지 않습니다"로 끝맺었습니다. 위에서 설명한 아이디어는 획기적인 변경이 아니며 100%는 아니지만 소스 해석과 관련하여 상대적으로 좋습니다. 그 회색 영역이 내가 TS 팀의 생각을 묻는 이유입니다.

@jods4 기존 구문을 유지하는 추론된 nullable any 선호합니다. 그리고 옵트인 전략이 바람직할 것입니다. [1]

nullable이 아닌 유형에 대한 명시적 구문을 선호합니다. 개체의 경우 한 번에 너무 많은 것을 깨뜨릴 것입니다. 또한 선택적 인수는 명백한 이유로 항상 null을 허용해야 합니다(변경이 불가능해야 함). 기본 인수는 외부적으로는 현재 서명을 유지해야 하지만 함수 자체 내부에서는 인수를 nullable이 아닌 것으로 만들 수 있습니다.

하지만 nullable 숫자는 엔진이 할 수 있는 많은 최적화를 깨고 선택적/기본 인수 이외의 일반적인 사용 사례가 아니기 때문에 이것이 터무니없다고 생각합니다. 컴파일러 플래그를 통해 기본적으로 null을 허용하지 않는 선택적 인수가 아닌 숫자를 만드는 것이 조금 더 실현 가능하거나 깨지지 않을 수 있습니다. 이것은 또한 명시적으로 nullable 형식을 표시하는 구문이 필요하지만 이 토론의 가능한 결과로 이미 보고 있습니다.

[1] 이것을 기본값으로 만드는 플래그를 도입하는 것은 실용적인 이유로 처음부터 잘 작동하지 않을 것입니다. 사람들이 --noImplicitAny 를 사용하여 직면한 문제를 살펴보십시오. 이로 인해 마이그레이션 위험이 발생했고, 속성 존재를 테스트 하는 데 실질적인 문제가 많이 발생 하여 --suppressImplicitAnyIndexErrors , 그리고 여러 가지 잘못된 ConfirmlyTyped 정의가 발생했습니다.

@impinball

기존 구문을 유지하는 유추된 nullable any 선호합니다. 그리고 옵트인 전략이 바람직할 것입니다.

여기에서 내 답변을 수정했습니다. 이것에 대해 더 생각해보면 암묵적으로 null 유형만 유추할 수 있는 유용한 경우가 없습니다. 예: () => null 또는 let x = null 또는 function y() { return null } .

따라서 any 계속 추론하는 것이 아마도 좋은 일이라는 데 동의합니다.

1. 이전 버전과 호환됩니다.
2. 그 모든 경우는 어쨌든 noImplicitAny 아래의 오류입니다.
3. 그렇게 하고 싶은 이상한 경우가 있고 유용한 경우 (): null => null 또는 let x: null = null 또는 function y(): null { return null } 유형을 명시적으로 선언할 수 있습니다.

nullable이 아닌 유형에 대한 명시적 구문을 선호합니다. 개체의 경우 한 번에 너무 많은 것을 깨뜨릴 것입니다.

string 실제로 string! | null 의미한다고 말하는 것은 또 다른 옵션일 수 있습니다. 위의 모든 논의를 읽으면 기존 코드와 더 호환될 것이라는 희망이 있었기 때문에 처음에 제안된 것임을 유의해야 합니다( string 의 현재 의미를 변경하지 않음). 그러나 사실 결론은 그렇다 해도 엄청난 양의 코드가 깨질 것이라는 것이었습니다.

nullable이 아닌 유형 시스템을 채택하는 것이 기존 코드베이스에 대해 사소한 전환이 되지 않을 것이라는 점을 감안할 때 string! 보다 string? 옵션을 선택하는 것이 더 깔끔해 보이기 때문입니다. 특히 TS 컴파일러 소스 코드를 보면 거의 모든 내부 유형의 이름이 부정확하게 지정됩니다.

컴파일러 플래그를 통해 기본적으로 null을 허용하지 않는 선택적 인수가 아닌 숫자를 만드는 것이 조금 더 실현 가능하거나 깨지지 않을 수 있습니다. 이것은 또한 명시적으로 nullable 형식을 표시하는 구문이 필요하지만 이 토론의 가능한 결과로 이미 보고 있습니다.

이 시점에서 상황이 혼란스러워지고 있다고 생각합니다. 나에게 이것은 string? 모든 곳에서 사용하는 좋은 주장처럼 보입니다. number? 와 string! 혼동하는 것을 보고 싶지 않습니다. 너무 빨리 혼란스러워집니다.

[1] 이것을 기본값으로 만드는 플래그를 도입하는 것은 실용적인 이유로 처음부터 잘 작동하지 않을 것입니다.

예, 변경하지 않으면 기존 코드 기반에서는 잘 작동하지 않습니다. 하지만:

1. 새로운 코드 기반에서 잘 작동합니다. 이를 통해 더 나은 미래를 건설할 수 있습니다.
2. 기존 코드 기반은 옵트인하지 않더라도 _일부_ 혜택과 추가 확인을 거둘 것입니다.
3. 기존 코드 기반은 파일 단위로 옵트인할 수 있으며, 이를 통해 새 코드를 더 엄격하게 만들고 원하는 경우 이전 코드를 점진적으로 전환할 수 있습니다.

@jods4

이 시점에서 상황이 혼란스러워지고 있다고 생각합니다. 나에게 이것은 문자열을 사용하는 좋은 주장처럼 보입니까? 어디에나. 숫자가 섞이는 것을 보고 싶지 않습니까? 그리고 string!, 이것은 너무 빨리 혼란스러워질 것입니다.

그런 의미에서 그런 뜻이 아니었어요. 나는 nullable 문자열보다 nullable 숫자에 대한 사용 사례가 적다는 것을 의미했습니다. 나는 그 제안에 그렇게 집착하지 않습니다. 어쨌든 (나는 어느 쪽이든 상관하지 않을 것입니다).

기존 코드 기반은 파일 단위로 옵트인할 수 있으며, 이를 통해 새 코드를 더 엄격하게 만들고 원하는 경우 이전 코드를 점진적으로 전환할 수 있습니다.

무슨 의미로? 현재 파일별로 컴파일러를 구성할 수 있다고 생각하지 않습니다. 나는 여기서 틀렸다는 것이 증명될 수 있습니다.

@impinball

무슨 의미로? 현재 파일별로 컴파일러를 구성할 수 있다고 생각하지 않습니다. 나는 여기서 틀렸다는 것이 증명될 수 있습니다.

내가 틀렸을 수도 있습니다. 나는 그것들을 사용한 적이 없지만 테스트 케이스를 볼 때 // <strong i="9">@module</strong> amd 처럼 보이는 많은 주석을 봅니다. 나는 항상 그것이 ts 파일 내부에서 옵션을 지정하는 방법이라고 가정했습니다. 나는 그것을 시도한 적이 없기 때문에 완전히 틀릴 수도 있습니다! 여기에서 예를 들어보세요.
https://github.com/Microsoft/TypeScript/blob/master/tests/cases/conformance/externalModules/amdImportAsPrimaryExpression.ts

이것이 파일별 옵션을 지정하는 방법이 아니라면 새로운 것이 필요할 수 있습니다. .d.ts 파일에 대해 _적어도_ 파일별로 이 옵션을 지정해야 합니다. 파일 맨 위에 있는 특별한 형식의 주석이 가능합니다. 결국 우리는 이미 /// <amd-dependency /> 및 co를 지원합니다.

편집 : 나는 틀렸다. 소스 코드를 Spelunking하면 이러한 것들이 마커라고 하며 FourSlash 러너에 의해 사전 구문 분석된다는 것을 알 수 있습니다. 따라서 테스트용일 뿐이며 컴파일러 내부에는 없습니다. 그러기 위해서는 새로운 무언가를 찾아야 할 것입니다.

어떤 경우에는 실용적인 제한도 있습니다. ES6 기능과 같은 일부 인수에는 가장 실용적이지 않습니다. 파일을 완전히 다시 구문 분석해야 하기 때문입니다. 그리고 IIUC 타입 검사는 애초에 AST 생성과 동일한 패스에서 이루어집니다.

파서 코드를 보면 /// <amd-dependency /> 및 /// <amd-module /> 주석이 파일에서 파싱되기 전에 읽혀집니다. /// <non-null-types /> 와 같은 것을 추가하는 것이 가능합니다. 네, 그건 끔찍한 명명이고 저는 임의의 "마법" 옵션의 확산에 찬성하지 않지만 그것은 단지 아이디어일 뿐입니다.

@ jods4 나는 @I 'm 핀볼은 십오 구문이 작품을 강조하는 방식에 큰 변화없이 지원하지 않습니다라고 생각합니다.

2.0에는 null을 허용하지 않는 형식이 있습니까?
결국 typescript는 유형을 보장할 수 없는 경우 자바스크립트에 가져오는 것이 매우 적습니다. 모든 문제를 극복하고 typescript에 의해 도입된 재작성 후에 얻을 수 있는 것은 무엇입니까?
IntelliSense가 더 낫습니까? 다른 모듈로 내보낼 때마다 수동으로 또는 코드별로 유형을 확인해야 하기 때문입니다.

좋은 소식입니다. TypeScript 1.6은 누락된 값을 모델링하고 안전하게 추적할 수 있는 충분한 표현력을 가지고 있습니다(그렇지 않으면 null 및 undefined 값으로 인코딩됨). 기본적으로 다음 패턴은 nullable이 아닌 유형을 제공합니다.

declare module Nothing { export const enum Brand {} }
interface Nothing { 'a brand': Nothing.Brand }
export type Nullable<a> = a | Nothing;
var nothing : Nothing = null;
export function isNothing(value: Nullable<a>): value is Nothing {
    return value == null;
}
var something = Math.random() > 0.5 ? 'hey!' : nothing;
if (isNothing(something)) {
    // missing value
    // there is no way you can get anything out of it
    // there is also NO WAY to get a null reference exception out of it
    // because it doesn't have any methods or properties that could be examined
    // it is 100% explicit and typesafe to use
} else {
    // value is present, it is 100% GUARANTEED being NON-NULL
    // you just CANT get a null reference exception here either
    console.log(something.toLowerCase());
}

/** turns any unsafe values into safe ones */
export function sanitize<a>(unsafe: a) : Nullable<a> {
    return unsafe;
}

var safe = sanitize(toResultFromExternalCodeYouCannotTrust()); // <-- 100% safe to use

더 이상 문제가 없기 때문에 요청을 닫아야 합니다. 케이스가 종료되고 수업이 종료되었습니다.

@aleksey-bykov

더 이상 문제가 없기 때문에 요청을 닫아야 합니다.

당신은 심각 할 수 없습니다, 그렇지? nullable 대수 유형에 대한 패턴은 이 문제에 대한 것이 아니라고 여러 번 말했습니다.

내 코드의 모든 var x: number 을 Nullable<number> 또는 더 나은 NonNullable<x> 로 래핑하지 _않습니다_. 너무 많은 오버헤드입니다. 그러나 x *= 2 것이 내 코드에서 발생하는 모든 곳에서 100% 안전하다는 것을 알고 싶습니다.

귀하의 코드는 타사 라이브러리 사용 문제를 해결하지 못합니다. 저는 _모든_ 타사 라이브러리에서 sanitize 를 호출하지 _않습니다_. 내가 호출하는 내장 DOM API도 마찬가지입니다. 게다가 나는 isNothing(safe) _사방에_를 추가하고 싶지 않습니다. 내가 원하는 것은 let squares = [1,2,3].map(x => x*x) 를 호출할 수 있고 컴파일 시간에 squares.length 가 안전하다는 것을 100% 확신할 수 있는 것입니다. 내가 사용하는 _any_ API로.

마찬가지로 함수가 null 를 입력으로 수락하는지 여부를 나타내는 타사 JS 라이브러리에 대한 문서를 원합니다. $(element).css(null) 가 정상인지 아니면 오류인지 컴파일 타임에 알고 싶습니다.

나는 모든 사람이 당신과 같은 복잡한 패턴을 일관되게 사용한다고 보장할 수 없는 팀 환경에서 일하고 싶습니다. 귀하의 Nulllable 유형은 개발자가 let x: number = null; x.toString() (또는 덜 멍청하지만 같은 효과를 내는 것)을 하는 것을 방지하는 데 전혀 아무 역할도 하지 않습니다.

등등. 이 티켓은 _멀리_ 종료되었으며 문제는 여전히 100% 있습니다.

당신은 심각 할 수 없습니다, 그렇지?

나는 꽤 진지하다.

일일이 포장하지 않겠습니다...

왜 안 돼? ! 구문이나 여러분이 추진하는 다른 무엇이든 사용하면 어쨌든 해야 합니다.

또는 더 나은 NonNullable

그것은 비 - 널 (NULL) 값 또는 null을 가질 수 nullable 형식이며, 명시 적으로 언급되어 우리가 모델링 Null 허용을해야합니다. 항상 값 또는 null을 가질 수 있고 number 로 호출될 수 있는 기존 유형과 달리 사용하기 전에 null이 있는지 확인해야 합니다.

너무 많은 오버헤드입니다.

어디에?

귀하의 코드는 타사 라이브러리 사용 문제를 해결하지 못합니다.

그렇습니다.

내가 호출하는 모든 타사 라이브러리 또는 내장 DOM API에 대해 Sanitize를 호출하지 않을 것입니다.

당신은 할 필요가 없습니다. null이 될 수 있는 모든 것을 Nullable<*> 로 대체하여 해당 타사 라이브러리의 정의 파일을 수정하기만 하면 됩니다.

마찬가지로 함수가 null을 입력으로 허용하는지 여부에 대한 타사 JS 라이브러리에 대한 문서를 원합니다.

같은 것. 그 메서드를 일반 string 대신 Nullable<string> 를 수락하도록 정의합니다.

Nullable 유형은 개발자가 let x: number = null; x.toString()

그렇지 않습니다. linter를 사용하여 null 키워드를 금지해야 합니다.

내 솔루션은 95% 작동하고 100% 실용적이며 어려운 결정을 내리거나 모든 사람을 같은 페이지로 만들 필요 없이 오늘 사용할 수 있습니다. 그것은 당신이 추구하는 것이 무엇인지에 대한 질문입니다. 당신이 기대하는 것처럼 보이지 않지만 그럼에도 불구하고 작동하는 작동하는 솔루션 또는 모든 백 잭과 체리를 맨 위에 놓고 원하는 방식으로 정확하게 얻는 것

1.4 및 1.5, 무효 형은로 .toString () 등을 포함하는 객체의 멤버, 그래서 허용하지 않습니다 type Nothing = void; 대신 (이 1.6에서 다시 변경하지 않는 한) 모듈을 필요로의 충분합니다. http://bit.ly/1OC5h8d

@aleksey-bykov 그건 사실이 아닙니다. null일 가능성이 있는 모든 값을 삭제하려면 여전히 주의해야 합니다. 잊어버리면 경고가 표시되지 않습니다. 확실히 개선되었습니다(조심해야 할 곳이 적음).

또한 해킹이 실제로 얼마나 멀리 갈 수 있는지 설명하려면 다음을 시도하십시오.

if (isNothing(something)) {
  console.log(something.toString())
}

일일이 포장하지 않겠습니다...

왜 안 돼? 와 함께 ! 구문이나 여러분이 추진하는 다른 것이 무엇이든 어쨌든 해야 할 것입니다.

다른 모든 것이 해결된다면 저는 _할 수 있습니다_. 그리고 모든 것이 해결된다면 TS는 이를 위해 약간의 언어 설탕을 고려할 수도 있습니다.

또는 더 나은 NonNullable

우리가 모델링하는 것은 nullable이어야 하며 nullable이 아닌 값이나 null을 가질 수 있고 명시적으로 명시되어 있는 nullable 유형입니다. 항상 값 또는 null을 가질 수 있고 number라고 부를 수 있는 기존 유형과 달리 사용하기 전에 null이 있는지 확인해야 합니다.

null 예외를 없애고 싶은 것이 아닙니다. nullable이 아닌 유형도 정적 안전성으로 표현할 수 있기를 원합니다.
항상 값을 반환하는 메서드가 있다고 가정해 보겠습니다. toString() 와 마찬가지로 항상 null이 아닌 문자열을 반환합니다.
거기에 당신의 선택은 무엇입니까?
let x: string = a.toString();
x.length 가 안전하다는 정적 검증이 없기 때문에 이것은 좋지 않습니다. 이 경우에는 그렇습니다. 하지만 당신이 말했듯이 내장 string 는 null 있으므로 _status quo_입니다.
let x = sanitize(a.toString());
이제 null 검사 없이 사용할 수 없으므로 코드가 _is_ 안전합니다. 하지만 내 코드에서 x 를 사용하는 모든 곳에 if (isNothing(x)) 를 추가하고 싶지 않습니다! x 가 컴파일 타임에 null이 아니라는 것을 잘 알 수 있기 때문에 추악하고 비효율적입니다. (<string>x).length 것이 더 효율적이지만 x 를 사용하려는 모든 곳에서 그렇게 해야 하는 것은 여전히 ​​지옥처럼 추악합니다.

내가 하고 싶은 것은:

let x = a.toString(); // documented, non-null type string (string! if you want to)
x.length; // statically OK

적절한 언어 지원 없이는 이를 달성할 수 없습니다. JS(및 TS 1.6)의 모든 유형은 항상 null을 허용하기 때문입니다.

선택 사항이 아닌(nullable) 유형을 사용하여 프로그래밍하는 것은 가능한 한 매우 좋은 방법이라고 말하고 싶습니다. 따라서 여기서 설명하는 것은 예외가 아닌 필수 시나리오입니다.

너무 많은 오버헤드입니다.

어디에?

내 이전 답변을 참조하십시오.

귀하의 코드는 타사 라이브러리 사용 문제를 해결하지 못합니다.

그렇습니다.

문제의 절반만 해결됩니다. 제안한 대로 라이브러리 정의가 업데이트되었다고 가정: 모든 nullable 입력 또는 반환된 값은 X 대신 Nullable<X> 로 대체됩니다.

null 매개변수를 허용하지 않는 함수에 null 를 전달할 수 있습니다. 자, 이 사실은 이제 _문서화__(이미 JSDoc 주석 또는 무엇이든 할 수 있음)하지만 컴파일 타임에 _적용_되기를 원합니다.
예: declare find<T>(list: T[], predicate: (T) => bool) . 두 매개변수 모두 null이 아니어야 합니다( Nullable 사용하지 않음). 아직 find(null, null) 할 수 있습니다. 또 다른 가능한 오류는 선언에서 술어에서 null이 아닌 bool 을 반환해야 한다고 명시되어 있지만 find([], () => null) 할 수 있다는 것입니다.

Nullable 유형은 개발자가 let x: number = null; x.toString()

그렇지 않습니다. linter를 사용하여 null 키워드를 금지해야 합니다.

그렇게 하고 대신 nothing 전역 변수를 제공하는 것은 제가 선례에 나열한 경우에 도움이 되지 않습니까?

내 관점에서 이것은 95%가 아니다. 많은 일반적인 것들에 대해 구문이 훨씬 더 나빠진 것처럼 느껴지고 nullable이 아닌 유형에 대해 이야기할 때 원하는 모든 정적 안전성이 여전히 없습니다.

null일 가능성이 있는 모든 값을 삭제하려면 여전히 주의해야 합니다.

여기에서 말하는 nullable이 아닌 가상의 유형으로 어쨌든 수행해야 하는 동일한 종류의 분리 작업입니다. 모든 정의 파일을 검토하고 적절한 위치에 ! 넣어야 합니다. 어떻게 다른가요?

잊어버리면 경고가 표시되지 않습니다.

같은 것. 같은 것.

해킹이 실제로 당신을 멀리 얻을 수 없다는 것을 보여줍니다. 그냥 시도하십시오.

toString from Object 가 있는 Nothing 을 정의한 방식은 옳았지만.. @Arnavion ( Nothing void 사용)의 아이디어를 취한다면 Nothing ) 갑자기 클릭

보다

내 관점에서 이것은 95%가 아니다. 많은 일반적인 것들에 대해 구문이 훨씬 더 나빠진 것처럼 느껴지고 nullable이 아닌 유형에 대해 이야기할 때 원하는 모든 정적 안전성이 여전히 없습니다.

이 패턴은 당신을 위한 것이 아니며 앞으로도 없을 것입니다. 코드에서 절대 사용하지 마세요. null이 허용되지 않는 실제 유형을 계속 요청하세요. 행운을 빕니다. 이런 말도 안되는 소리로 귀찮게 해서 죄송합니다.

@aleksey-bykov
나는 당신이 무엇을 하려고 하는지 알지만, 당신은 아직 모든 경우를 다 정리하지 않은 것 같고 누군가가 구멍을 지적할 때 ( null 의 대체와 같이) 길을 따라 솔루션을 만드는 것 같습니다 void 로).

결국 _어쩌면_ 내가 원하는 방식으로 작동하게 될 것입니다. nullable 형식에 대해 복잡한 구문을 사용하고 프로그램에서 null 소스를 linter로 금지하여 결국 nullable 형식을 null이 아닌 것으로 만들 수 있습니다. 그 과정에서 비표준 규칙을 사용하여 라이브러리를 업데이트하도록 모든 사람을 설득해야 합니다. 그렇지 않으면 아무 소용이 없습니다.

결국 내장 null 유형을 피하고 원하는 검사를 Nothing 유형에 첨부하도록 유형 시스템을 비틀는 데 성공할 수 있습니다.

이 시점에서 언어가 지원해야한다고 생각하지 않습니까? 언어는 (내부적으로) 원하는 것과 거의 동일한 방식으로 모든 것을 구현할 수 있습니다. 그러나 그 위에 멋진 구문, 가장자리 케이스 정리, 외부 린터가 필요하지 않으며 확실히 타사 정의에서 더 나은 채택이 가능합니다. 그게 더 말이 되지 않습니까?

이 시점에서 언어가 지원해야한다고 생각하지 않습니까?

내 생각에 대해 이야기해 봅시다. 내일 TypeScript에 nullable이 아닌 유형이 있는 세상에서 깨어나면 좋을 것 같습니다. 사실 이 생각은 매일 밤 잠자리에 든다. 하지만 다음날 그런 일이 일어나지 않고 나는 좌절합니다. 그런 다음 나는 직장에 가서 최근에 내 삶을 더 쉽게 만들 수 있는 패턴을 찾기로 결정했을 때까지 null로 동일한 문제를 반복했습니다. 찾은 것 같습니다. TypeScript에서 nullable이 아니었으면 하는 바램이 있습니까? 물론 내가 하는 일. 나는 그들과 좌절 없이 살 수 있습니까? 할 수 있을 것 같습니다.

TypeScript에서 nullable이 아니었으면 하는 바램이 있습니까? 물론 내가 하는 일.

그렇다면 왜 이 문제를 종료하시겠습니까? : 스마일 :

더 이상 문제가 없기 때문에 요청을 닫아야 합니다. 케이스가 종료되고 수업이 종료되었습니다.

귀하의 요구 사항에 맞는 솔루션을 찾은 것을 기쁘게 생각하지만 귀하와 마찬가지로 언젠가는 TS가 적절한 지원을 받을 수 있기를 바랍니다. 그리고 나는 이것이 여전히 일어날 수 있다고 믿습니다. C# 팀은 현재 동일한 브레인스토밍을 하고 있으며 앞으로 나아가는 데 도움이 될 수 있습니다. C# 7이 null이 아닌 유형을 얻을 수 있다면(아직 확실하지 않음) TS가 동일한 작업을 수행하지 않을 이유가 없습니다.

@aleksey-bykov

그래서 단순화하기 위해

var nothing: void = null;
function isNothing<a>(value: a | void): value is void {
    return value == null;
}
var something = Math.random() > 0.5 ? 'hey!' : nothing;

이제 함수 래퍼 없이도 사용할 수 있습니다. 적절한 유형 정의로 충분합니다.

그것 은 기본 적으로 그것 에 의존 하는 것을 낙담 할 때까지 나를 약간 행복하게 만들었던 해결 방법 입니다 .

모든 정의 파일을 검토하고 ! 적절한 경우. 어떻게 다른가요?

핵 대신 표준 공식 언어 기능을 사용할 때의 주요 차이점은 커뮤니티(DefinitelyTyped)가 프로젝트 위에 쌓이는 모든 추가 작업 대신 정의 파일을 작성, 테스트 및 공유하는 데 도움이 된다는 것입니다. :웃다:).

저는 " --noImplicitNull "를 옹호합니다. 그러면 모든 유형이 nullable이 아닌 기본값으로 설정되어 기존 코드의 잠재적인 문제에 대한 피드백을 즉시 제공합니다. "!"가 있으면 typechecker가 null 가능성(nullable이 아닌 것으로의 안전하지 않은 캐스트)을 무시하도록 하기 위해 Swift처럼 행동해야 합니다. 비록 그것이 약속에 대한 ES7+ "최종 보내기" 연산자 와 충돌하므로 최선이 아닐 수도 있습니다. 아이디어.

이전 버전과의 호환성 손상이라는 측면에서 너무 급진적으로 보인다면 그건 정말 내 잘못입니다. 나는 정말로 시간을 찾고 포크에서 시도하여 그것이 실제로 보이는 것처럼 급진적이지 않다는 것을 증명해야 합니다. 사실 추가 "!" 더 급진적입니다. 대부분의 값이 실제로 null이 아니기 때문에 이를 활용하려면 더 많은 변경이 필요합니다. --noImplicitNull 는 null이 아닌 값을 잘못 주장하는 유형 정의를 수정하여 더 많은 오류를 발견하고 이러한 수정 없이는 null 할당, 초기화되지 않은 값 및 선택적 개체 필드에 대한 잊어버린 검사를 제외하고 동일한 동작을 얻게 되므로 더 점진적입니다. .

토론에 내 목소리를 더하면 Kotlin이 문제를 해결한 방식이 마음에 듭니다.

• 자체 변수에는 기본적으로 '?' 변경
• 외부 변수는 '!!' 재정의
• null 검사는 유형 캐스트입니다.
• 주석을 생성하는 도구로 외부 코드를 분석할 수 있습니다.

비교하다:
1
2

• 경우 a|void 하나가로 전환 할 수 있습니다 금지 a|Nothing

핵 대신 표준 공식 언어 기능을 사용할 때의 주요 차이점은 커뮤니티(DefinitelyTyped)가 정의 파일을 작성, 테스트 및 공유하는 데 도움이 된다는 것입니다.

• 100% 합법적인 기능을 사용하는 것이 해킹인 이유를 알 수 없습니다.
• 커뮤니티의 기술을 과대평가하지 마십시오. 많은(대부분은 아니지만) 정의의 품질이 낮고 jquery와 같은 정의도 약간의 변경 없이 작성된 대로 사용할 수 없는 경우가 많습니다.
• 다시 말하지만, 패턴은 완전한 기능만큼 좋지 않을 것입니다. 모든 사람이 이해하기를 바랍니다. 의심의 여지가 없습니다.
• 패턴은 오늘날 문제를 해결할 수 있지만 기능은 근처에 있을 수도 있고 그렇지 않을 수도 있습니다.
• 상황이 AB와 C를 사용하여 효율적으로(최대 95%) 해결될 수 있다면 왜 누군가에게 D가 필요할까요? 약간의 설탕을 갈망? 패턴으로 해결할 수 없는 일에 집중하지 않는 이유는 무엇입니까?

어쨌든 문제 해결사와 완벽주의자가 있습니다.

(만약 당신이 void 타입에 의존하고 싶지 않다면, Nothing 도 같은 효과를 낼 class Nothing { private toString: any; /* other Object.prototype members */ } 수 있습니다. #1108 참조)

_참고: 여기에서는 구문을 바이크쉐딩하는 것에 대한 내용이 없습니다. 받지마세요
그대로._

간단히 말하겠습니다. 제안된 TS 1.6 솔루션의 문제점은 다음과 같습니다.
여기: 가능하게 작동할 수 있지만 표준 라이브러리 또는
대부분의 정의 파일. 수학 연산자에도 적용되지 않습니다. 네가 원한다면
중복 유형/런타임 상용구에 대해 불평하려면 제네릭을 시도하십시오.
컬렉션은 C ++에서 작동합니다. 특히 원하는 경우 비교하면 창백합니다.
배열이 아닌 게으른 반복 또는 컬렉션(또는 더 나쁘게는
둘을 결합).

@aleksey-bykov가 현재 제안한 솔루션의 문제는
언어 코어에서는 적용되지 않습니다. 예를 들어, 당신은 할 수 없습니다
Object.defineProperty(null, "name", desc) - 다음에서 TypeError가 발생합니다.
null 대상 개체. 또 다른 사항: 속성을 할당할 수 없습니다.
null 에서 같은 객체, var o = null; o.foo = 'foo'; . 당신은 얻을 것이다
참조 오류 IIRC. 이 제안된 솔루션은 이러한 경우를 설명할 수 없습니다.
이것이 언어 지원이 필요한 이유입니다.

_이제, 약간의 가벼운 자전거 이동..._

그리고 구문에 관해서는 "?string"의 간결함과
"!string" 구문이지만 최종 결과에 관한 한 나는 상관하지 않습니다.
ThisIsANullableType<T, U, SomeRidiculousAndUnnecessaryExtraGeneric<V, W>> 쓰지 않습니다.

2015년 7월 29일 수요일 16:10 Aleksey Bykov 알림 @github.com에서 다음과 같이 썼습니다.

• |void가 금지된 경우|아무것도 전환할 수 있습니다.

  표준 공식 언어 기능을 사용할 때의 주요 차이점
  해킹 대신 커뮤니티(DefinitelyTyped)가 도움을 주기 위해 존재합니다.
  정의 파일 작성, 테스트 및 공유

  100% 합법적인 기능을 사용하는 것이 해킹인 이유를 알 수 없습니다.

  커뮤니티의 기술을 과대평가하지 마십시오(대부분은 아니지만).
  품질이 낮고 jquery와 같은 정의도 있습니다.

  종종 약간의 변경 없이 작성된 대로 사용할 수 없습니다.

  다시 말하지만 패턴은 완전한 기능만큼 좋지 않을 것입니다.

  모든 사람이 이해합니다. 의심의 여지가 없습니다.

  패턴은 오늘날 문제를 해결할 수 있지만 기능은

  가까이에 있지 않다

  AB를 사용하여 상황을 효율적으로(최대 95%) 해결할 수 있는 경우
  그리고 C 왜 누군가 D가 같은 일을 해야 합니까? 약간의 설탕을 갈망? 왜 그럴까
  패턴으로 해결할 수 없는 문제에 집중합니까?

어쨌든 문제 해결사와 완벽주의자가 있습니다.
문제는 해결할 수 있습니다

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/Microsoft/TypeScript/issues/185#issuecomment -126082053
.

그리고 어떤 색으로 칠할지 고민하기 전에 자전거 창고 구조가 어떻게 생겼는지 적어도 알 수 있을까요? 처음 ~10개의 댓글 이후에 제가 지금까지 본 것의 대부분은 "이봐, 우리는 자전거 보관소를 만들고 싶어! 무슨 색으로 칠할까?" 디자인이 구조적으로 건전한지 확인하는 것은 중요하지 않습니다. (이에 대한 몇 가지 다른 예는 #3192와 #1206의 전반부를 참조하십시오. 내가 마침내 논리적으로 생성된 구문과 완전히 지정된 의미론으로 진지한 제안을 했을 때 대부분의 노이즈가 사라졌습니다.)

명심하십시오: 이것은 표준 라이브러리 유형 정의의 주요 리팩터링 및 부분 재작성을 초래할 가능성이 매우 높습니다. 또한 이를 지원하는 TS의 첫 번째 버전에 대해 재작성해야 하는 DefinedTyped의 유형 정의 대부분이 발생합니다. 따라서 이것은 확실히 깨질 것임을 명심하십시오. (해결책은 null 관련 오류가 발생하더라도 기본적으로 항상 발생하지만 해당 동작을 변경하기 위해 --noImplicitAny 플래그를 제공하는 것일 수 있습니다.)

분명히 나는 ​​여기에서 약간 이상합니다. 그러나 나는 "nullable javascript" 및 "nullability javascript"에 대해 studer.google을 검색했습니다.
TypeScript 이해하기
TypeScript(모듈 제네릭)에 멋진 유형 테이블이 있습니다.

JavaScript의 종속 유형
중요한 것 같습니다. 소스 코드가 사라졌다

신뢰하되 확인: 동적을 위한 2단계 입력언어
스크립팅 언어의 구체화 유형
typescript 기반의 솔루션을 제공합니다.
("약칭 t?는 t + null을 나타냅니다." ; #186처럼 들립니다)

@afrische 이것의 대부분은 이미 JS 유형 검사기에서 실제로 사용되고 있습니다. 예를 들어 Flow는 "Trust, but Verify"에서 대부분의 관용구를 사용합니다. Infernu 도 있습니다. WIP JS 유형 검사기는 주로 Hindley-Milner 유형 추론 1 에 의존하여 유형을 추론합니다. 하지만 난 탈당...

[1] Haskell, OCaml 등도 해당 유형 시스템에 대해 수정된 버전을 사용합니다.

저는 현재 유형이 기본적으로 nullable이 아니라고 가정하고 null 와 같이 (기존) Null 유형을 참조할 수 있도록 하는 TS 포크를 가지고 놀고 있습니다(예: string | null . 또한 동일한 공용체 유형에 대한 바로 가기인 string? 대한 구문을 추가했습니다.

곰곰이 생각해보면 @aleksey-bykov와 같지만 null 는 Nothing 형식으로 내장되어 있습니다.

그리고 유형 시스템이 이미 이 모든 것을 잘 처리하기 때문에 수행하는 것이 복잡하지도 않습니다!

문제가 발생하는 부분은 부드러운 전환 경로를 원하기 때문입니다. 우리는 기존 정의 파일과 _적어도_ 일부 하위 호환성이 필요합니다(프로젝트 자체와의 호환성은 옵트인 플래그가 될 수 있지만 인터넷에서와 같이 코드 조각의 의미가 t 전역 컴파일러 플래그에 따라 다름).

사용 @afrische의 아이디어 string? 자신의 프로젝트에 있지만 사용하여 string! 에서 .d.ts 새로운 접근 방식이 될 수 있습니다. 비록 그것이 만들어내는 자의적인 이중성을 별로 좋아하지는 않지만. string null을 허용하고 일부 파일은 null을 허용하지 않는 이유는 무엇입니까? 이상한 것 같다.

일부 파일에서는 문자열을 null 허용하지 않고 다른 파일에서는 허용하지 않는 것을 선호하는 경우.
컴파일러에 옵트아웃 플래그가 있고 이를 주요 변경 사항으로 도입하는 @impinball 의 아이디어가 마음에

이 스레드는 1년이 넘었고 거의 300개의 댓글과 TS 팀 자체의 소수에 불과하여 모든 관련 디자인과 우려 사항이 무엇인지 파악하기 어렵습니다.

대규모 코드베이스를 Flow, Closure Compiler 또는 TypeScript로 마이그레이션할 계획이지만 TypeScript에 null 안전이 없다는 것은 정말 큰 문제입니다.

전체 스레드를 읽지 않고는 ! 및 ? null 허용 여부 지정자를 모두 추가하는 동시에 이들이 부족한 유형에 대한 기존 동작을 유지하는 것이 잘못된 점을 파악할 수 없습니다

제안

declare var foo:string // nullability unspecified
declare var foo:?string // nullable
declare var foo:!string // non-nullable

함께 ?string 의 수퍼 !string 및 string 수퍼 둘 모두의 부분 집합, 즉 관계 string 모두 ?string !string 는 any 와 다른 모든 유형 간의 관계와 동일합니다. 즉, ! 또는 ? 가 없는 베어 유형은 any 와 같습니다.

다음 규칙이 적용됩니다.

| 유형 | 포함 | 제공 | null 할당할 수 있습니까? | null 아니라고 가정할 수 있습니까? |
| --- | --- | --- | --- | --- |
| T | T , !T , ?T | T , ?T , !T | 네 | 네 |
| ?T | T , !T , ?T | T , ?T | 네 | 아니오(타입 가드 필요) |
| !T | T , !T | T , ?T , !T | 아니 | 네 |

이것은 기존 코드를 깨뜨리지 않고 null 안전을 제공하고 any 기존 코드베이스가 유형 안전을 점진적으로 도입할 수 있도록 하는 것처럼 기존 코드베이스가 점진적으로 null 안전을 도입할 수 있도록 합니다.

예시

다음은 null 참조 오류가 있는 일부 코드입니다.

function test(foo:Foo) { foo.method(); }
test(null);

이 코드는 여전히 통과합니다. null 는 여전히 Foo 할당할 수 있고 Foo 는 여전히 null이 아닌 것으로 가정할 수 있습니다.

function test(foo:!Foo) { foo.method(); }
test(null);

null 는 !Foo 할당할 수 없기 때문에 이제 test(null) 는 오류입니다.

function test(foo:?Foo) { foo.method(); }
test(null);

이제 foo.bar() 에 메소드 호출 이후에 오류가 ?Foo 허용되지 않습니다 (즉 코드가 확인해야합니다 null ).

감사합니다! 그리고 저는 이 아이디어가 정말 좋습니다. 호환성을 위해
?T 및 T Array<T> 및 T[] 와 같은 별칭으로 만들 수 있습니까? 그것
일을 단순화하고 장식되지 않은 버전은 여전히 ​​기술적으로
널 입력 가능.

2015년 8월 28일 금요일 07:14 Jesse Schalken [email protected]에서 다음과 같이 썼습니다.

이 스레드는 1년이 넘었고 모든 것이 무엇인지 파악하기 어렵습니다.
관련 디자인과 우려 사항은 거의 300개에 달하는 댓글과 소수에 불과합니다.
TS 팀 자체에서.

대규모 코드베이스를 Flow, Closure Compiler 또는
TypeScript 그러나 TypeScript의 유형 안전 부족은 실제 거래 차단기입니다.

전체 스레드를 읽지 않고 무엇이 잘못되었는지 잘 알 수 없습니다.
둘 다 추가하면 ! 그리고 ? 유지하면서 null 허용 여부 지정자
그것들이 없는 유형에 대한 기존 동작, 그래서 여기에 제안입니다:
제안

선언 var foo:string // null 허용 여부 지정되지 않음declare var

?string을 사용하여 !string의 상위 집합을, 문자열을 사용하여 상위 집합과 하위 집합을 모두
둘 다, 즉 string과 ?string 및 !string 모두의 관계
다른 모든 유형 간의 관계와 동일합니다. 즉,
없는 베어 타입! 또는 ? 무효화와 관련하여 모든 것과 같습니다.

다음 규칙이 적용됩니다.
유형 포함 제공 null을 할당할 수 있습니까? null이 아니라고 가정할 수 있습니까? ㅜ, ! , ? ,
?T, !T 예 예 ?TT, !T, ?TT, ?T 예 아니요(유형 가드 필요) !TT, !TT,
?T, !T 아니요 예

이것은 기존 코드를 깨뜨리지 않고 null 안전을 제공하고
기존 코드베이스와 마찬가지로 점진적으로 null 안전을 도입합니다.
기존 코드베이스에서 유형 안전성을 점진적으로 도입할 수 있습니다.
예시

다음은 null 참조 오류가 있는 일부 코드입니다.

함수 테스트(foo:Foo) { foo.method(); } 테스트(널);

이 코드는 여전히 통과합니다. null은 여전히 ​​Foo에 할당할 수 있고 Foo는 여전히 할당할 수 있습니다.
null이 아닌 것으로 가정합니다.

함수 테스트(foo:!Foo) { foo.method(); } 테스트(널);

이제 !Foo에 null을 할당할 수 없기 때문에 test(null)에 오류가 있습니다.

함수 테스트(foo:?Foo) { foo.method(); } 테스트(널);

이제 foo.bar()에 오류가 있습니다. ?Foo에 대한 메서드 호출이 허용되지 않기 때문입니다.
(즉, 코드는 null을 확인해야 합니다).

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/Microsoft/TypeScript/issues/185#issuecomment -135743011
.

@impinball

감사합니다! 그리고 저는 이 아이디어가 정말 좋습니다. 하지만 호환성을 위해 Array<T> 및 T[] 와 같이 Array<T> ?T 및 T 를 별칭으로 만들 수 있습니까? 그것은 일을 단순화하고 장식되지 않은 버전은 여전히 ​​기술적으로 nullable입니다.

_전체 아이디어_는 T , ?T 및 !T 가 세 가지 별개의 것이며 호환성을 위해 _is_한다는 것입니다(기존 TS 코드와의 호환성). 어떻게 더 잘 설명해야 할지 모르겠습니다. 죄송합니다. 내 말은, 나는 작은 테이블과 모든 것을 만들었습니다.

괜찮아. 좋은 지적. 그 부분에 대한 표를 잘못 해석해서 간과한
기존 정의 파일이 전환되는 경우 문제가 발생합니다.
다른 응용 프로그램 및 라이브러리.

2015년 8월 28일 금요일 11:43 Jesse Schalken [email protected]에서 다음과 같이 썼습니다.

@impinball https://github.com/impinball

감사합니다! 그리고 저는 이 아이디어가 정말 좋습니다. 호환성을 위해
Array와 같은 별칭으로 T와 T를 만들 수 있습니까?그리고 T[]? 그것은 것
일을 단순화하고 장식되지 않은 버전은 여전히 ​​기술적으로 nullable입니다.

_전체 아이디어_는 T, ?T 및 !T가 세 가지 별개의 것입니다.
그리고 그것은 호환성을 위해 _is_입니다(기존 TS와의 호환성
암호). 어떻게 더 잘 설명해야 할지 모르겠습니다. 죄송합니다. 내 말은, 내가 만든
작은 테이블과 모든 것.

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/Microsoft/TypeScript/issues/185#issuecomment -135810311
.

똑똑한 놈이라 미안하지만 이건 말이 안 돼

?string 상위의 !string 및 string 수퍼 둘 모두의 부분 집합

집합 이론에서 우리는 집합 A가 부분집합이고 집합 B의 상위 집합이 A = B일 때만 있다는 것을 압니다.

그렇다면 "둘 다"라고 말할 때 문자열의 모든 것 = 문자열의 모든 것과 문자열의 모든 것 = 문자열의 모든 것을 의미할 수 있습니다.

그래서 궁극적으로 all-of-?string = Everything-of-!string

모두가 내리는 곳에서 버스는 아무데도 가지 않고 버스는 운행하지 않습니다.

@aleksey-bykov 아마도 잘못된 표현의 경우일 것입니다. 나는 그가 string 가 ?string | !string 가장 관대한 제약 조건을 취하는 것과 비슷하다는 것을 의미한다고 생각합니다.

이 모든 것은 점점 더 일반적으로 사용되는 Java의 @Nullable 및 @NonNull / @NotNull 컴파일 타임 유형 주석과 주석이 없는 유형과 함께 작동하는 방식과 범위가 비슷합니다.

그리고 암시적으로 nullable이 아닌 것으로 간주되는 유형, 특히 기본 형식에 대한 새 플래그를 선호합니다.

"기본적으로 nullable이 아님" 플래그가 있으면 좋겠지만 많은 확실히 Typed 정의가 손상될 수도 있습니다. 여기에는 Angular 및 Node의 정의가 포함되며 수정하는 데 많은 지루한 작업이 필요합니다. 또한 백포트가 필요할 수 있으므로 새 유형은 여전히 ​​구문 오류로 구문 분석되지 않지만 null 허용 여부는 확인되지 않습니다. 이러한 백포트는 특히 nullable 형식에 대한 정의가 업데이트될 때 이러한 플래그로 손상을 완화하는 유일한 실용적인 방법입니다. (사람들은 개발, 특히 대규모 프로젝트에서 여전히 TypeScript 1.4를 사용합니다.)

@impinball

사람들은 개발, 특히 대규모 프로젝트에서 여전히 TypeScript 1.4를 사용합니다.

이 기능에 대한 호환성 이야기는 새 정의를 이전 컴파일러와 호환되도록 만들지 않고 이미 충분히 어렵다고 생각합니다(FWIW가 아닌 null 유형은 현재 TS 컴파일러에 추가하는 것이 거의 간단합니다).

사람들이 이전 TS를 계속 사용한다면 이전 정의를 사용해야 합니다. (나는 그것이 실용적이지 않다는 것을 알고 있습니다).
어쨌든 일이 깨질 거란 말이야. 곧 TS 1.6은 교차 유형을 추가하고 이를 사용하는 정의도 호환되지 않습니다.

BTW 사람들이 1.4에 머무르고 있다는 사실에 놀랐습니다. 1.5에는 사랑해야 할 것이 너무 많습니다.

@aleksey-bykov

똑똑한 놈이라 미안하지만 이건 말이 안 돼

나는 당신이 포스트의 나머지 부분에서 "두 가지의 상위 집합과 하위 집합"이 의미하는 바를 완벽하게 알고 있기 때문에 스스로를 "똑똑한 엉덩이"라고 부르고 있다고 가정합니다. 물론 실제 세트에 적용하면 말도 안 된다.

any 는 모든 유형을 할당할 수 있고(모든 유형의 상위 집합으로 작동) 모든 유형으로 처리됩니다(모든 유형의 하위 집합으로 작동). any 는 "이 값에 대한 유형 검사 선택 해제"를 의미합니다.

string 는 !string 또는 ?string 둘 다에서 할당될 수 있으며(이것의 상위 집합으로 작동함) !string 및 ?string 둘 다로 처리될 수 있습니다. string 는 "이 값에 대한 null 허용 여부 검사에서 제외", 즉 현재 TS 동작을 의미합니다.

@impinball

그리고 암시적으로 nullable이 아닌 것으로 간주되는 유형, 특히 기본 형식에 대한 새 플래그를 선호합니다.

@RyanCavanaugh는 명시적으로 다음과 같이 말했습니다.

언어의 의미를 바꾸는 플래그는 위험한 것입니다. [...] 코드 조각을 보는 사람이 유형 시스템을 "따라갈" 수 있고 만들어지는 추론을 이해할 수 있다는 것이 중요합니다. 언어의 규칙을 변경하는 많은 플래그를 갖기 시작하면 이는 불가능해집니다.

유일하게 안전한 방법은 할당 가능성의 의미를 동일하게 유지하고 현재 noImplicitAny 작동하는 방식과 마찬가지로 플래그에 의존하지 않는 것과 오류가 있는 것을 변경하는 것입니다.

이것이 내 제안이 null 허용 여부 지정자가 없는 유형( ! 또는 ? )에 대한 기존 동작을 유지하는 이유입니다. 추가할 _only_ 안전한 플래그는 null 허용 여부 지정자가 없는 유형을 허용하지 않는 것입니다. 즉, 전달 코드만 가져와서 오류를 발생시키고 의미는 변경하지 않습니다. 같은 이유로 noImplicitAny 가 허용되었다고 가정합니다.

@jesseschalken

암시적으로 유형이 지정된 변수의 컨텍스트에서 초기화되지 않음을 의미했습니다.
null 또는 undefined 로 다음과 같은 경우:

var a = new Type(); // type: !Type
var b = 2; // type: !number
var c = 'string'; // type: !string
// etc...

혼란을 드려 죄송합니다.

2015년 8월 28일 금요일 19:54 Jesse Schalken [email protected]에서 다음과 같이 썼습니다.

@impinball https://github.com/impinball

그리고 나는 유형에 대한 새로운 플래그에 확실히 찬성할 것입니다.
암시적으로 nullable이 아닌 것으로 간주되며, 특히 기본 형식입니다.

@RyanCavanaugh https://github.com/RyanCavanaugh는 명시적으로 다음과 같이 말했습니다.

언어의 의미를 바꾸는 플래그는 위험한 것입니다. [...]
코드 조각을 보고 있는 사람이 "따라갈 수" 있는 것이 중요합니다.
유형 시스템을 사용하여 수행되는 추론을 이해합니다. 만약에
우리는 언어의 규칙을 변경하는 많은 플래그를 갖기 시작했습니다.
이것은 불가능해집니다.

유일하게 안전한 종류의 일은 다음의 의미를 유지하는 것입니다.
할당 가능성은 동일하고 오류가 있는 것과 종속되지 않은 것을 변경합니다.
오늘날 noImplicitAny가 작동하는 방식과 매우 유사합니다.

이것이 내 제안이 부족한 유형에 대한 기존 동작을 유지하는 이유입니다.
null 허용 여부 지정자(! 또는 ?). 추가할 _only_ 안전 플래그는 다음과 같습니다.
null 허용 여부 지정자가 없는 유형을 허용하지 않는 것, 즉
전달 코드를 받아 오류를 발생시키더라도 의미는 변경되지 않습니다. 나
같은 이유로 noImplicitAny가 허용되었다고 가정합니다.

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/Microsoft/TypeScript/issues/185#issuecomment -135916676
.

@jeffmcaffer 단어 상위 집합과 하위 집합의 원래 의미를 변경하여 말하려는 내용은 여전히 ​​집합의 관점에서 쉽게 표현될 수 있습니다. string 값 집합은 !string 값의 조합 입니다 !string 및 ?string 는 !string 또는/및 ?string 가 string 속하는 것을 의미합니다.

@impinball 다시 말하지만, 이러한 플래그는 @RyanCavanaugh 의 주석 읽기에서 허용되지 않는 기존 코드의 의미를 변경합니다. export var b = 5; 는 이제 !number 내보냅니다. 이전에는 number 내보냈습니다.

예, 어떤 의미에서. 좀 더 테크니컬하게 말하면 Union을 받아들이지만
교차점을 제공합니다. 기본적으로 두 유형 모두
string 및 string 는 두 유형 모두에 전달할 수 있습니다.

2015년 8월 28일 금요일 20시 20분 Aleksey Bykov [email protected]이 다음과 같이 썼습니다.

@impinball https://github.com/impinball 하려는 말
단어의 상위 집합과 하위 집합의 원래 의미를 변경하는 것은 여전히 ​​일 수 있습니다.
집합의 관점에서 쉽게 표현됨: 문자열 값의 집합은 다음과 같습니다.
!string 및 ?string 값의 _union_은 !string의 모든 것을 의미합니다.
또는/및 ?string은 string에 속합니다.

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/Microsoft/TypeScript/issues/185#issuecomment -135920233
.

물론 기본적으로 켜져 있는 것은 아닙니다. 그리고 대부분의 정의 파일
영향을 받지 않을 것입니다. 기술적으로 순수하지 않은 모든 변경
추가(함수에 새 인수를 추가하는 것조차도 JavaScript에는 없음)가 있습니다.
응용 프로그램을 중단하는 능력. 와 범위가 비슷하다.
noImplicitAny 는 좀 더 명시적인 입력을 강요한다는 점에서. 그리고 나
그것보다 훨씬 더 많이 깨질 수 있다고 믿지 마십시오.
이것이 다른 파일에 영향을 줄 수 있는 방법은 실제 TypeScript에서 내보내는 것입니다.
소스 파일. (다른 플래그는 수많은 정의 파일을 깨고 비활성화되었습니다.
오리 테스트의 빈번한 방법)

2015년 8월 28일 금요일 20:21 Jesse Schalken [email protected]이 다음과 같이 썼습니다.

@impinball https://github.com/impinball 다시 말하지만, 그러한 플래그는 변경될 것입니다.
기존 코드의 의미(@RyanCavanaugh 읽기에서
https://github.com/RyanCavanaugh의 코멘트)는 허용되지 않습니다. 내보내기 변수
b = 5; 이제 이전에 숫자를 내보낸 !number를 내보냅니다.

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/Microsoft/TypeScript/issues/185#issuecomment -135920315
.

물론 기본적으로 켜져 있는 것은 아닙니다.

그것은 여전히 ​​코드의 의미를 변경하고 있습니다. 그렇게 하자마자 일부 TypeScript 코드를 읽고 "이것이 무엇을 의미하는지 압니다"라고 말할 수 없으며 코드의 의미가 사용되는 플래그에 따라 다르기 때문에 다른 사람이 사용할 라이브러리를 작성할 수도 없습니다. 그것을 컴파일하고 그것은 받아 들일 수 없습니다. 말 그대로 언어를 둘로 나누었습니다.

이것이 내 제안이 null 허용 여부 지정자가 없는 유형( ? 또는 ! )에 대한 기존 동작을 유지하는 이유입니다.

@jesseschalken
기존 코드의 의미를 100% 충실하게 유지하고 관리하려면 타이프스크립트에서 null 안전에 대한 아이디어를 포기해야 합니다. 실제로 사용할 수 있는 솔루션은 없습니다.

모든 유형 주석에 ? 및 ! 를 입력해야 하는 것은 이미 내가 하고 싶지 않을 정도로 장황하지만 모든 유형 추론을 포기해야 합니다. let x = 3 는 오늘 number 추론합니다. 여기에서 변경 사항을 수락하지 않으면 null 안전의 이점을 누리기 위해 모든 것을 명시적으로 입력해야 함을 의미합니다. 나도 하고 싶은 일이 아니다.

장점이 단점보다 클 때 약간의 양보가 이루어질 수 있습니다. @impinball 에서 지적한 바와 같이 TS 팀은 noImplicitAny 정확히 해냈습니다. 켤 때 코드에 새로운 오류를 생성하는 플래그입니다. 따라서 인터넷에서 코드를 복사하여 붙여넣거나 TS 라이브러리를 사용하는 것만으로도 가져온 코드가 noImplicitAny 가정에 따라 작성되지 않은 경우 중단될 수 있습니다.

null 안전도 비슷한 방식으로 도입할 수 있다고 생각합니다. 코드의 의미는 동일하며 정확히 동일한 의미로 실행됩니다. 그러나 새 플래그( noImplicitNull ) 아래에서는 noImplicitNull 가정으로 작성되지 않은 코드에서 추가 검사 및 경고/오류가 발생합니다.

null 안전도 비슷한 방식으로 도입할 수 있다고 생각합니다. 코드의 의미는 동일합니다.
정확히 동일한 의미로 실행됩니다. 그러나 새 플래그 아래(noImplicitNull 또는 무엇이든 말함)
다음으로 작성되지 않은 코드에서 추가 검사 및 경고/오류가 발생합니다.
noImplicitNull 가정.

나는 그 접근 방식을 좋아하고 언어를 발전시키는 논리적인 방법인 것 같습니다. 나는 시간이 지남에 따라 타이핑이 일반적으로 noImplicitAny를 염두에 두고 작성되는 것과 같은 방식으로 사실상의 표준이 되기를 바랍니다.

그러나 점진적 채택에 관한 한 중요한 것은 기존 코드를 한 번에 모듈로 마이그레이션할 수 있고 명시적 null을 염두에 두고 작성된 새 코드가 암시적 null을 사용하는 기존 코드와 쉽게 작동할 수 있도록 하는 것입니다.

그렇다면 이것은 어떻습니까?

• -noImplicitNull을 사용하면 T 가 !T 의 별칭이 됩니다. 그렇지 않으면 T 의 null 허용 여부를 알 수 없습니다.
• 플래그는 상단에 주석을 추가하여 모듈별로 재정의할 수 있어야 합니다. <strong i="18">@ts</strong>:implicit_null . 이는 Flow가 모듈별로 유형 검사를 활성화하는 방식과 유사합니다.
• 기존 코드베이스 변환은 먼저 -noImplicitNull 컴파일러 옵션을 추가한 다음 모든 기존 모듈에 ' @ts :implicit_null' 플래그를 추가하여 수행됩니다. 이 두 번째 단계는 간단하게 자동화될 수 있습니다.
• 모듈을 가져올 때 가져온 모듈과 가져오는 모듈의 암시적 설정이 다른 경우 유형을 변환하는 방법에 대한 정책이 필요합니다.

명시적 null이 있는 모듈이 암시적 null이 있는 모듈을 가져오는 경우 마지막 지점에 대해 다른 옵션이 있습니다.

• 극단적인 접근 방식은 T 유형의 null 허용 여부를 알 수 없는 것으로 처리하고 수입자가 유형을 ?T 또는 !T 로 명시적으로 캐스트하도록 요구하는 것입니다. 그것은 호출 수신자에 많은 주석이 필요하지만 안전합니다.
• 또 다른 접근 방식은 가져온 모든 T 유형을 ?T 입니다. 이것은 또한 호출자에서 많은 주석을 필요로 합니다.
• 마지막으로 가져온 모든 T 유형은 !T 로 처리될 수 있습니다. 물론 이것은 어떤 경우에는 틀릴 수 있지만 가장 실용적인 옵션일 수 있습니다. any 유형의 변수가 T 유형의 값에 할당될 수 있는 방식과 유사합니다.

생각?

@jods4 noImplicitAny 플래그는 기존 코드의 의미를 변경하지 _않습니다_. 그렇지 않으면 암시적일 것에 대해 코드가 명시적이어야만 합니다.

| 코드 | 깃발 | 의미 |
| --- | --- | --- |
| interface Foo { blah; } | | interface Foo { blah:any; } |
| interface Foo { blah; } | noImplicitAny | 오류, 명시적 유형 필요 |
| var foo = 'blah' | | var foo:string = 'blah' |
| var foo = 'blah' | noImplicitNull | var foo:!string = 'blah' |

noImplicitNull 를 사용하면 null을 쓸 수 있는 변수가 있기 전에. 이제 null _cannot_ 쓸 수 있는 변수가 있습니다. noImplicitAny 완전히 다른 짐승입니다.

@RyanCavanaugh 는 이미 기존 코드의 의미를 변경하는 플래그를 배제했습니다. TS 팀의 명시적 요구 사항을 단호하게 무시한다면 이 티켓은 1년 더 버틸 것입니다.

@jesseschalken 죄송하지만 차이점을 보지 못했습니다.
noImplicitAny 전에 코드에 다음이 있을 수 있습니다.
let double = x => x*2;
컴파일되고 잘 작동합니다. 그러나 noImplicitAny 를 켜면 컴파일러는 x 가 암시적으로 any라는 오류를 발생시킵니다. 새 플래그와 함께 작동하도록 코드를 수정해야 합니다.
let double = (x: any) => x*2 이상 let double = (x: number) => x*2 .
컴파일러에서 오류가 발생했지만 여전히 완벽하게 작동하는 JS 코드를 내보냅니다(오류 발생 시 방출을 끄지 않는 한).

null의 상황은 내 생각에 거의 동일합니다. 새 플래그를 사용하여 T 가 nullable이 아니고 T? 또는 T | null T 및 null 유형의 합집합을 나타낸다고 가정해 보겠습니다.
전에:
let foo: string; foo = null; 또는 let foo = "X"; foo = null string 로 추정됩니다.
컴파일되고 잘 작동합니다. 이제 새로운 noImplicitNull 플래그를 켭니다. 갑자기 TS는 명시적으로 선언되지 않은 항목에 null 를 할당할 수 없다는 오류를 표시합니다. 그러나 타이핑 오류를 제외하고 귀하의 코드는 여전히 _동일한_ 올바른 JS 코드를 내보냅니다.
플래그를 사용하면 의도를 명시적으로 명시하고 코드를 수정해야 합니다.
string? foo; foo = null;

차이점은 무엇입니까? 코드는 항상 정상적으로 출력되고 런타임 동작은 전혀 변경되지 않았습니다. 두 경우 모두 타이핑 시스템에서 오류가 발생하고 이러한 오류를 제거하려면 유형 선언에서 더 명시적으로 코드를 수정해야 합니다.

또한 두 경우 모두 strict 플래그로 작성된 코드를 가져와 플래그를 끈 상태로 컴파일해도 오류 없이 동일하게 작동합니다.

@robertknight 내 현재 생각에 매우 가깝습니다.

엄격한 null이 아닌 유형을 선택하지 않은 모듈/정의의 경우 T 는 기본적으로 다음을 의미해야 합니다. 이 유형에서 모든 종류의 null 오류를 끕니다. T? 로 강제하려고 하면 여전히 호환성 문제가 발생할 수 있습니다.

문제는 오늘날 일부 T 는 실제로 nullable이 아니고 일부는 nullable이라는 것입니다. 고려하다:

// In a strict module, function len does not accept nulls
function len(x: string): number { return x.length; }
// In a legacy module, some calls to len
let abc: string = "abc";
len(abc);

레거시 모듈에서 string 별칭을 string? 로 지정하면 null 가능성이 있는 변수를 null을 허용하지 않는 매개변수에 전달하기 때문에 호출이 오류가 됩니다.

@jods4 내 댓글을 다시 읽어보세요. 테이블을 보세요. 더 명확하게 표현하는 방법을 모르겠습니다.

귀하의 예를 명시 적으로 정의 넣어 당신의 결론에 도달하기 위해 제작 된 foo 와 할당을 foo 서로 옆에. noImplicitAny 를 사용하면 결과적으로 발생하는 유일한 오류는 특히 변경해야 하는 코드에서 발생합니다(그 의미가 변경되지 않았기 때문에 더 명시적으로 표현되기만 하면 됨). noImplicitNull 에서 오류를 일으킨 코드는 foo 에 대한 _assignment_ 였지만 수정하기 위해(이전 의미를 갖기 위해) 변경해야 하는 코드는 foo 의 _definition_이었습니다 foo 정의의 의미를 _변경했기 때문에 이것은 매우 중요합니다. 할당과 정의는 분명히 라이브러리 경계의 다른 쪽에 있을 수 있습니다. noImplicitNull 플래그가 해당 라이브러리의 공용 인터페이스 _의미_를 변경했습니다!

플래그는 foo 정의의 의미를 변경했습니다.

응 그것은 사실이야. "변수가 null을 보유할 수 있는지 여부를 조금도 알 수 없고 -- 그냥 상관하지 않습니다."에서 "이 변수는 null이 없습니다."로 변경되었습니다. 그것이 옳았을 가능성은 50/50이고 그렇지 않은 경우 선언에서 의도를 정확하게 해야 합니다. 결국 결과는 noImplicitAny 와 동일합니다. 선언에서 의도를 더 명시해야 합니다.

할당과 정의는 분명히 라이브러리 경계의 다른 쪽에 있을 수 있습니다.

실제로, 일반적으로 라이브러리의 선언과 내 코드에서의 사용. 지금:

1. 라이브러리가 엄격한 null을 선택한 경우 해당 유형을 올바르게 선언해야 합니다. 라이브러리에 엄격한 null 유형이 있고 x 가 null을 허용하지 않는 것으로 표시되면 null을 할당하려고 하는 것은 _실제로 보고되어야 하는 오류입니다_.
2. 라이브러리가 엄격한 null을 선택하지 않은 경우 컴파일러는 사용에 대해 오류를 발생시키지 않아야 합니다.

이 플래그( noImplicitAny 와 유사)는 코드를 조정하지 않고는 켤 수 없습니다.

나는 당신의 요점을 알지만 우리는 의미 코드를 _변경_하지 않습니다. 오히려 우리는 오늘날 유형 시스템에 의해 _표현되지 않는 의미를 표현합니다.

이것은 오늘날 코드에서 오류를 잡아내기 때문에 좋을 뿐만 아니라 그러한 단계를 거치지 않고는 TS에서 사용 가능한 null이 아닌 유형이 절대 없을 것이라고 말하고 싶습니다.

nullable이 아닌 유형에 대한 희소식입니다! TS 팀이 TS 업데이트의 주요 변경 사항을 도입하는 데 괜찮은 것 같습니다!
다음과 같이 표시됩니다.
http://blogs.msdn.com/b/typescript/archive/2015/09/02/announcing-typescript-1-6-beta-react-jsx-better-error-checking-and-more.aspx
그들은 새로운 파일 유형으로 주요 변경 사항(상호 배타적인 선택적 구문)을 도입하고, 새로운 파일 유형 없이 _없는_ 주요 변경 사항을 도입합니다(모든 사람에게 영향을 미침).
이것은 우리가 nullable이 아닌 유형(예: .sts 또는 엄격한 Typescript 확장 및 해당 .sdts)과 논쟁할 수 있는 선례입니다.

이제 컴파일러가 정의되지 않은 유형 또는 null 유형(그리고 어떤 구문)을 확인하려고 하는지 파악해야 하며 확실한 제안이 있습니다.

@jbondc 매우 흥미롭게 읽었습니다. NNBD(기본적으로 nullable이 아님)로의 마이그레이션이 선택적 non-nullable로 마이그레이션하는 것보다 쉽다는 나의 직감이 연구(마이그레이션할 변경 사항이 10배 적음, Dart의 경우 1- 코드 1000줄당 2개의 주석에 nullity 변경이 필요하며 null이 많은 코드에서도 10개 이하)

문서의 복잡성이 실제로 nullable이 아닌 유형의 복잡성을 반영하는지 잘 모르겠습니다. 예를 들어, 제네릭 섹션에서는 3가지 유형의 형식 매개변수에 대해 논의한 다음 실제로 이러한 매개변수가 필요하지 않음을 보여줍니다. TS에서 null 는 단순히 완전히 비어 있는 레코드의 유형(속성, 메서드 없음)이 되는 반면 {} 는 루트가 아닌 null 유형이 되고 null을 허용하지 않는 제네릭은 단순히 G<T extends {}> - 여러 종류의 형식 매개변수에 대해 논의할 필요가 전혀 없습니다.

또한 var !x 와 같은 비필수 설탕을 많이 제안하는 것 같습니다.

그러나 동일한 문제를 처리한 기존 언어에 대한 설문조사는 진정한 보석입니다.

문서를 읽으면서 Optional / Maybe 유형이 nullable 유형보다 더 강력하다는 것을 깨달았습니다. 특히 일반 컨텍스트에서 - 주로 Just(Nothing) 를 인코딩할 수 있기 때문입니다. 예를 들어 T 유형의 값을 포함하고 키의 존재 여부에 따라 값을 반환하거나 반환하지 않을 수 있는 get 를 지원하는 일반 Map 인터페이스가 있는 경우:

interface Map<T> {
  get(s:string):Maybe<T>
}

T 가 Maybe<U> 유형이 되는 것을 방해하는 것은 없습니다. 코드는 완벽하게 잘 작동하고 돌아갑니다 Just(Nothing) 키가 존재하지만이 포함 된 경우 Nothing 값을 단순히 반환 Nothing 키가 전혀 존재하지 않는 경우입니다.

반대로 nullable 형식을 사용하는 경우

interface Map<T> {
  get(s:string):T?
}

T 가 nullable

어느 쪽이든, nullable과 non-nullable 값을 구별하고 그에 따라 사용 가능한 메서드와 속성을 모델링하는 기능은 모든 유형의 안전을 위한 전제 조건입니다.

@jbondc 이것은 매우

연구에 따르면 선언의 80%가 실제로 null이 아님을 의미하거나 KLOC당 nullity 주석이 20개뿐이라는 연구 결과(p. 21)가 있다는 것이 위안이 됩니다. 문서에 언급된 바와 같이 이것은 기본적으로 null이 아닌 것에 대한 강력한 주장이며 내 느낌이기도 합니다.

: null 이외의 찬성 또 다른 인수는 깨끗한 형식 시스템 생성한다는 것입니다 null 자신의 유형입니다 T 입니다 null이 아닌 및 T? 동의어입니다 T | null . TS에는 이미 유니온 유형이 있기 때문에 모두 훌륭하고 깨끗하며 잘 작동합니다.

그 문제를 다룬 최근 언어 목록을 보면 새로운 현대 프로그래밍 언어가 이 오랜 문제를 처리하고 코드 기반의 null 버그를 줄여야 한다고 생각합니다. 이것은 유형 시스템에서 모델링되어야 하는 것에 대해 너무 일반적인 문제입니다. 나는 여전히 TS가 언젠가 그것을 얻을 수 있기를 바랍니다.

T! 연산자가 흥미롭고 유용할 수 있다는 아이디어를 찾았습니다. T 가 null이 아닌 유형이고 T? 가 T | null 있었습니다. 하지만 null 입력에도 불구하고 null이 아닌 결과를 보장하는 일반 API를 실제로 생성할 수 없다는 것이 나를 귀찮게 했습니다. 좋은 사용 사례가 없지만 이론상 function defined(x) { return x || false; } 충실하게 모델링할 수 없습니다.
null이 아닌 반전 연산자를 사용하여 function defined<T>(x: T): T! | boolean 수행할 수 있습니다. defined 이 T 반환하면 일반 T 제약 조건이 nullable이더라도 null이 아닌 것으로 보장됩니다(예 string? . 그리고 TS에서 모델링하는 것은 어렵지 않다고 생각합니다. T! 주어졌을 때 T 가 null 유형을 포함하는 공용체 유형이면 null 조합에서

@spion

문서를 읽고 나는 Optional / Maybe 유형이 nullable 유형보다 더 강력하다는 것을 깨달았습니다.

Maybe 구조를 중첩할 수 있지만 실제로 null 중첩할 수 없습니다.

이것은 새로운 API를 정의하는 맥락에서 흥미로운 논의이지만 기존 API를 매핑할 때는 선택의 여지가 거의 없습니다. 언어 맵 Null을 Maybe 로 만드는 것은 함수를 완전히 다시 작성하지 않는 한 해당 이점을 활용하지 않습니다.

Maybe 는 값이 있는지 여부와 값이 무엇인지의 두 가지 고유한 정보를 인코딩합니다. Map 예제를 사용하고 C#을 보면 Dictionary<T,K> 에서 이것이 분명합니다.
bool TryGet(K key, out T value) .
C#에 튜플이 있는 경우(아마도 C# 7) 이는 기본적으로 다음과 같습니다.
(bool hasKey, T value) TryGet(K key)
기본적으로 Maybe 이고 null 저장할 수 있습니다.

JS에는 이 문제를 처리하는 고유한 방법이 있으며 undefined 와 같은 새로운 흥미로운 문제가 많이 생성됩니다. 일반적인 JS Map 는 키가 없으면 undefined 반환하고, 그렇지 않으면 null 포함하여 값을 반환합니다.

C# 7 관련 제안 - https://github.com/dotnet/roslyn/issues/5032

같은 방식으로 undefined를 모델링하지 않으면 문제가 해결되지 않는다는 것을 알고 있습니까?
그렇지 않으면 모든 null 문제가 정의되지 않은 문제로 대체됩니다(어쨌든 이 문제가 더 널리 퍼져 있음).

@그리포크

모든 null 문제는 정의되지 않은 문제로 대체됩니다.

아니, 왜 그럴까요?
내 null 문제가 사라지고 정의되지 않은 문제가 남아 있습니다.

사실, undefined 는 여전히 문제입니다. 그러나 이는 코딩 스타일에 따라 크게 달라집니다. 브라우저에서 강제로 적용하는 경우를 제외하고는 undefined 하지 않고 코드를 작성합니다. 즉, null 검사를 사용하면 코드의 90%가 더 안전할 것입니다.

브라우저에서 강제로 적용하는 경우를 제외하고는 거의 정의되지 않은 상태로 코딩합니다.

JavaScript가 매 턴마다 undefined 를 강제 실행한다고 생각했을 것입니다.

• 초기화되지 않은 변수. let x; alert(x);
• 함수 인수를 생략했습니다. let foo = (a?) => alert(a); foo();
• 존재하지 않는 배열 요소에 액세스합니다. let x = []; alert(x[0]);
• 존재하지 않는 개체 속성에 액세스합니다. let x = {}; alert(x['foo']);

반면에 Null은 더 적고 예측 가능한 상황에서 발생합니다.

• DOM 액세스. alert(document.getElementById('nonExistent'));
• 타사 웹 서비스 응답( JSON.stringify 스트립 undefined ) . { name: "Joe", address: null }
• 정규식.

이러한 이유로 우리는 null 의 사용을 금지하고 유선을 통해 수신된 모든 null 를 undefined 로 변환하고 항상 undefined 대해 엄격한 평등 검사를 사용합니다. 이것은 실제로 우리에게 효과적이었습니다.

결과적으로 나는 undefined 문제가 더 널리 퍼진 문제라는 데 동의합니다.

@NoelAbrahams 코딩 스타일 알려드립니다 :)

초기화되지 않은 변수

나는 항상 변수를 초기화하고 noImplicitAny 켜두므로 let x 는 어쨌든 오류가 됩니다. 내 프로젝트에서 사용할 근접기는 let x: any = null . 비록 자주 작성하지는 않는 코드지만 말입니다.

선택적 기능 매개변수

나는 선택적 매개변수에 대해 기본 매개변수 값을 사용하는데, 그것이 더 의미가 있는 것 같습니다(귀하의 코드는 매개변수를 읽고 어떻게든 사용하지 않습니까?). 그래서 나를 위해: function f(name?: string = null, options?: any = {}) .
원시 undefined 매개변수 값에 액세스하는 것은 저에게 _예외_ 경우가 될 것입니다.

존재하지 않는 배열 요소에 접근하기

이것은 내 코드에서 하지 않으려고 노력하는 것입니다. 범위를 벗어나지 않도록 배열 길이를 확인하고 희소 배열을 사용하지 않습니다(또는 null , 0 , ...와 같은 기본값으로 빈 슬롯을 채우려고 시도).
다시 말하지만, 내가 그렇게 할 특별한 경우를 생각해 낼 수 있지만 그것은 규칙이 아니라 _예외_가 될 것입니다.

존재하지 않는 개체 속성에 액세스합니다.

배열의 경우와 거의 동일합니다. 값은 내가로 설정을 사용할 수없는 경우 내 객체는, 입력되는 null 하지 undefined . 다시 한 번 당신은 (사전 조사를 하는 것과 같은) 극단적인 경우를 찾을 수 있지만 그것들은 _엣지 케이스_이고 내 코딩 스타일을 대표하지 않습니다.

undefined 돌려받는 모든 _예외적인_ 경우에는 즉시 undefined 결과에 대한 조치를 취하고 더 이상 전파하거나 "작업"하지 않습니다. null 검사를 사용하는 가상 TS 컴파일러의 일반적인 실제 예:

let cats: Cat[];
// Note that find returns undefined if there's no cat named Kitty
let myFavoriteCat = cats.find(c => c.name === 'Kitty'); 
if (myFavoriteCat === undefined) {
  // Immediately do something to compensate here:
  // return false; or 
  // myFavoriteCat = new Cat('Kitty'); or
  // whatever makes sense.
}
// Continue with assurance that myFavoriteCat is not null (it was an array of non-nullable cats after all).

이러한 이유로 우리는 null 사용을 금지하고 유선을 통해 수신된 모든 null을 undefined 로 변환하며 항상 undefined 에 대해 엄격한 동등 검사를 사용합니다. 이것은 실제로 우리에게 효과적이었습니다.

이것으로 나는 당신이 나와 매우 다른 코딩 스타일을 사용한다는 것을 이해합니다. 기본적으로 모든 곳에서 undefined 사용한다면 정적으로 확인된 null 유형이 나보다 훨씬 적은 이점을 얻을 수 있습니다.
일 것이다.

예, undefined 때문에 100% 방수가 되지 않으며 이 점에서 100% 정확하고 합리적으로 사용 가능한 언어를 만들 수 없다고 생각합니다. JS는 너무 많은 곳에서 undefined 를 소개합니다.

그러나 위의 내 답변에서 알 수 있기를 바랍니다. 적절한 코딩 스타일을 사용하면 null 검사의 이점이 _많이_ 있습니다. 적어도 내 의견은 내 코드 기반에서 많은 어리석은 버그를 찾아 방지하고 내 팀 환경에서 생산성을 향상시키는 데 도움이 될 것이라는 것입니다.

@jods4 , 당신의 접근 방식을 읽는 것이 흥미로웠습니다.

그 접근 방식에 대한 반대 의견은 준수해야 할 규칙이 많다는 것입니다. 오히려 공산주의 대 자유 시장과 비슷합니다.미소:

TS팀은 내부적 으로 저희와 비슷한 스타일

@NoelAbrahams " undefined "은 " null 사용"과 같은 규칙입니다.

어쨌든 일관성이 핵심이며 null 또는 undefined (또는 빈 문자열 또는 0)이어야 하는지 확실하지 않은 프로젝트는 좋아하지 않습니다. 특히 TS는 현재이 문제에 도움이되지 않기 때문에 ...

나는 TS가 선호하는 규칙이 알고 undefined 이상 null 선택 뒤에 이상의 인수가있는 경우이 선택 또는 "일관성을 위해서"임의의 경우, 내가 궁금합니다.

내가 사용하려는 이유는 null 보다는 undefined :

1. 그것은 우리 개발자들에게 친숙한 방식으로 작동하며 많은 사람들이 C#과 같은 정적 OO 언어에서 왔습니다.
2. 초기화되지 않은 변수는 일반적으로 많은 언어에서 코드 냄새로 간주되며 JS에서는 왜 달라야 하는지 잘 모르겠습니다. 의도를 분명히 하세요.
3. JS는 동적 언어이지만 변경되지 않는 정적 유형이 성능이 더 좋습니다. 속성을 null 보다 delete null 로 설정하는 것이 더 효율적입니다.
4. 그것은 간의 차이 깨끗 지원 null 정의하지만 값이 없음을 의미하고, undefined ... 정의되지 않는다. 둘 사이의 차이가 분명한 곳: 선택적 매개변수. 매개변수를 전달하지 않으면 undefined 됩니다. 코드 기반에서 undefined 를 사용하는 경우 빈 값을 어떻게 _pass_합니까? null 사용해도 문제 없습니다.
5. 이것은 undefined 실제로 실용적이지 않은 이 스레드에서 논의된 것처럼 null 검사에 대한 깨끗한 경로를 제시합니다. 비록 내가 이것에 대해 공상을 하고 있을지도 모르지만.
6. 일관성을 위해 선택해야 합니다. IMHO null 는 undefined 만큼 좋습니다.

undefined 를 null 보다 선호하는 이유는 다음과 같습니다.
obj.nonexistentProp 반환의 기본 인수 및 일관성
undefined .

그 외에는 null로 간주되는 항목에 대해 bikeshedding을 이해하지 못합니다.
변수가 nullable이어야 하기에 충분합니다.

2015년 9월 8일 화요일 06:48 jods [email protected]에서 다음과 같이 작성했습니다.

@NoelAbrahams https://github.com/NoelAbrahams "정의되지 않은 사용"은 다음과 같습니다.
"널 사용"과 같은 규칙입니다.

어쨌든 일관성이 핵심이고 내가 있는 프로젝트를 좋아하지 않습니다.
사물이 null인지 정의되지 않은(또는 비어 있는지) 확실하지 않습니다.
문자열 또는 0). 특히 TS는 현재 이를 지원하지 않기 때문에
문제...

TS에 null보다 undefined를 선호하는 규칙이 있다는 것을 알고 있습니다.
"일관성을 위해" 임의적인 선택이거나 더 많은 경우
선택 뒤에 있는 주장.

_I_가 정의되지 않은 것보다 null을 사용하는 것을 좋아하는 이유:

1. 우리 개발자들에게 친숙한 방식으로 작동하며 많은 사람들이 정적 OO에서 나옵니다.
   C#과 같은 언어.
2. 초기화되지 않은 변수는 일반적으로 코드 냄새로 간주됩니다.
   많은 언어, 왜 JS에서 달라야 하는지 잘 모르겠습니다. 너의 ~을 만들어라
   의도가 분명하다.
3. JS는 동적 언어이지만 다음을 사용하면 성능이 더 좋습니다.
   변경되지 않는 정적 유형. 속성을 다음으로 설정하는 것이 더 효율적입니다.
   삭제하는 것보다 null입니다.
4. 정의된 null 사이의 명확한 차이를 지원하지만
   값의 부재를 의미하고 undefined는... undefined를 의미합니다.
   둘의 차이가 분명한 곳: 선택 사항
   매개변수. 매개변수를 전달하지 않으면 정의되지 않습니다. 당신은 어떻게
   _pass_ 코드에서 undefined를 사용하는 경우 빈 값
   베이스? null을 사용하면 여기에 문제가 없습니다.
5. 이 항목에서 논의된 것처럼 null 검사에 대한 깨끗한 경로를 제시합니다.
   스레드는 undefined로 실제로 실용적이지 않습니다. 아마도
   나는 이것에 대해 공상을 하고 있다.
6. 일관성을 위해 선택해야합니다. IMHO null은 다음과 같습니다.
   찾으시는 주소가 없습니다.

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/Microsoft/TypeScript/issues/185#issuecomment -138514437
.

@impinball
모든 github 토론에서 "bikeshedding" 사용을 중지할 수 있나요? undefined 또는 null 를 사용하는 것이 팀 기본 설정이라고 안전하게 말할 수 있습니다. 그러나 null 검사에 undefined 를 포함할지 여부와 작동 방식에 대한 문제는 간단하지 않습니다. 그래서 나는 그것이 처음부터 어떻게 자전거를 몰고 가는지 이해하지 못합니까?

nullable이 아닌 유형으로 TS 1.5의 포크를 구축했으며 놀라울 정도로 쉬웠습니다. 그러나 공식 TS 컴파일러에서 nullable이 아닌 형식을 갖기 위해 합의가 필요한 두 가지 어려운 문제가 있다고 생각합니다. 둘 다 위에서 명확한 결론 없이 길게 논의되었습니다.

1. undefined 무엇을 할까요? (내 의견: 여전히 도처에 있고 확인되지 않음)
2. 기존 코드, 특히 정의와의 호환성을 어떻게 처리합니까? (내 의견: 최소한 정의 파일당 플래그를 선택합니다. null 주석을 추가해야 할 수 있기 때문에 플래그를 켜는 것은 "중단"입니다.)

내 개인적인 의견은 null과 undefined를 처리해야 한다는 것입니다.
무효화를 위해 동등하게. 둘 다 해당 사용 사례에 사용되며,
값이 없음을 나타냅니다. 하나는 가치가 존재하지 않는다는 것입니다.
다른 하나는 가치가 한때 존재했지만 더 이상 존재하지 않는다는 것입니다. 둘 다
null 허용 여부를 계산해야 합니다. 대부분의 JS 함수는 정의되지 않은 값을 반환하지만 많은
DOM 및 라이브러리 함수는 null을 반환합니다. 둘 다 동일한 사용 사례를 제공합니다. 따라서,
동등하게 취급해야 합니다.

bikeshedding 참조는 코드 스타일 인수에 대한 것이었습니다.
값이 없음을 나타내는 데 사용해야 합니다. 일부는 주장
그냥 null, 일부는 정의되지 않은 것에 대해 논쟁하고 일부는 논쟁 중입니다.
혼합물. 이 제안은 그 중 한 가지에만 국한되어서는 안 됩니다.

2015년 9월 8일 화요일 13:28 jods [email protected]에서 다음과 같이 작성했습니다.

@impinball https://github.com/impinball
모든 github 토론에서 "bikeshedding" 사용을 중지할 수 있나요? 우리는 안전하게
undefined 또는 null을 사용하는 것이 팀 기본 설정이라고 말합니다. 하지만 문제
null 검사에 undefined를 포함할지 여부와 방법
그것은 사소한 일이 아닙니다. 그래서 나는 그것이 어떻게 자전거를 타고 가는지 이해하지 못합니다.
처음?

나는 nullable이 아닌 유형으로 TS 1.5의 포크를 만들었습니다.
의외로 쉽습니다. 하지만 두 가지 어려운 문제가 있다고 생각합니다.
공식 TS 컴파일러에서 nullable이 아닌 유형을 가지려면 합의가 필요합니다.
두 가지 모두 명확한 결론 없이 위에서 길게 논의되었습니다.

1. undefined로 무엇을 합니까? (내 생각: 여전히 도처에
   및 선택 취소)
2. 특히 기존 코드와의 호환성을 어떻게 처리합니까?
   정의? (내 의견: 최소한 정의 파일당 옵트인 플래그.
   플래그를 켜는 것은 null을 추가해야 할 수 있기 때문에 "중단"입니다.
   주석.)

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/Microsoft/TypeScript/issues/185#issuecomment -138641395
.

@jods4 귀하의 포크가 명시적 nullable이 아닌 유형 주석을 요구하는 대신 기본적으로 non-nullable 유형을 유추한다는 점 2에서 가져

링크 부탁드려도 될까요? 나는 그것을 시도하고 싶습니다.

@impinball
undefined 에 대한 (일부) 안전도 보고 싶지만 상당히 만연합니다.

특히 nullable이 아닌 유형의 배열을 정의할 수 있습니까?
범위를 벗어난(또는 희소한) 배열 액세스가 undefined 반환한다면 배열을 편리하게 정의하고 사용할 수 있습니까?
모든 배열이 null을 허용하도록 요구하는 것은 실제로 너무 많은 부담이 된다고 생각합니다.

null 및 undefined 유형을 구별해야 합니까? 그것은 어렵지 않습니다: T | null , T | undefined , T | null | undefined 위의 질문에 대한 쉬운 대답을 제공할 수 있습니다. 그러나 속기 구문은 어떻습니까? T? 는 무엇을 의미합니까? null과 undefined 모두? 두 개의 다른 속기가 필요합니까?

@아르나비온
Null 및 Undefined 유형이 이미 TS에 있습니다.
내 생각은 다음과 같습니다.

1. 모든 유형을 nullable이 아닌 것으로 설정합니다(추론된 유형 포함).
2. null 유형에 유형 선언에 사용할 수 있는 이름( null )을 지정합니다.
3. null 에서 any 확장 제거 ;
4. T | null 와 동일한 구문 속기 T? T | null ;
5. null 에서 다른 유형으로의 암시적 변환을 제거합니다.

내 소스에 대한 액세스가 없으면 그것이 요지라고 생각합니다. 기존의 Null 유형과 멋진 TS 유형 시스템(특히 Union 유형 및 유형 가드)이 나머지를 수행합니다.

아직 github에서 작업을 커밋하지 않았으므로 지금은 링크를 공유할 수 없습니다. 호환성 스위치를 먼저 코딩하고 싶었지만 다른 일로 매우 바빴습니다 :(
호환성 스위치는 훨씬 더 복잡합니다 <_<. 그러나 지금 당장은 TS 컴파일러가 많은 오류로 자체 컴파일되고 많은 기존 테스트가 실패하기 때문에 중요합니다.
그러나 실제로 새로운 코드에서 잘 작동하는 것 같습니다.

이 대화가 서클에서 어떻게 진행되고 있는지 설명할 수 있기를 바라며 지금까지 일부 댓글 작성자로부터 본 것을 요약하겠습니다.
문제: 특정 '특수 사례' 값은 언어의 다른 모든 유형(예: null 및 undefined)과 다르게 취급되기 때문에 처리하도록 설계되지 않은 코드에서 발견되었습니다.
나: 그런 문제가 발생하지 않도록 프로그래밍 표준을 세우는 것이 어떻습니까?
기타: 의도가 타이핑에 반영될 수 있다면 좋을 것이기 때문에 타입 스크립트에서 작업하는 모든 팀에서 다르게 문서화되지 않고 타사 라이브러리에 대한 잘못된 가정이 덜 발생하기 때문입니다.
Everone: 이 문제를 어떻게 처리할까요?
기타: null을 더 엄격하게 만들고 표준을 사용하여 undefined를 처리합시다!

undefined가 null보다 훨씬 더 문제일 때 이것이 어떻게 해결책으로 간주될 수 있는지 모르겠습니다!

면책 조항: 이것은 여기 있는 모든 사람의 태도를 반영하지 않으며, 내가 이것을 강조하고 싶었을 정도로 충분히 떠올랐습니다.
이것이 받아들여질 수 있는 유일한 방법은 그것이 문제의 작은 부분에 대한 약간의 해결책이 아니라 문제에 대한 해결책인 경우입니다.

댕 폰!
*여러분

* 강조하고 싶을 정도로 올라왔습니다.

또한 마지막 단락은 "이 제안의 유일한 방법"으로 읽어야 합니다.

@jods4 특정 구성에 따라

declare const list: T![];

for (const entry of list) {
  // `entry` is clearly immutable here.
}

list.forEach(entry => {
  // `entry` is clearly immutable here.
})

list.map(entry => {
  // `entry` is clearly immutable here.
})

이 경우 컴파일러는 배열이 범위 내에서 확인되도록 하기 위해 수많은 논리를 가져야 합니다.

declare const list: T![]

for (let i = 0; i < list.length; i++) {
  // This could potentially fail if the compiler doesn't correctly do the static bounds check.
  const entry: T![] = list[i];
}

그리고 이 경우 실제로 코드의 일부를 평가하지 않고 컴파일러가 entry 를 얻기 위한 액세스가 범위 내에 있는지 확인할 수 있다고 보장할 수 있는 방법은 없습니다.

declare const list: T![]

const end = round(max, list.length);

for (let i = 0; i < end; i++) {
  const entry: T![] = list[i];
}

쉽고 분명한 것도 있지만 더 어려운 것도 있습니다.

@impinball 실제로 map , forEach 또는 for..of 와 같은 최신 API는 초기화되거나 삭제되지 않은 요소를 건너뛰기 때문에 괜찮습니다. (여기에는 undefined 로 설정된 요소가 포함되지만 가상의 null-safe TS는 이를 금지합니다.)

그러나 고전적인 배열 액세스는 중요한 시나리오이며 이에 대한 좋은 솔루션을 보고 싶습니다. 당신이 제안한 대로 복잡한 분석을 하는 것은 사소한 경우를 제외하고는 분명히 불가능합니다(그러나 그것들은 일반적이기 때문에 중요한 경우입니다). 그러나 i < array.length 증명할 수 있더라도 요소가 초기화되었음을 증명하지는 않습니다.

다음 예를 생각해 보십시오. TS가 해야 할 일은 무엇입니까?

let array: T![] = [];  // an empty array of non-null, non-undefined T
// blah blah
array[4] = new T();  // Fine for array[4], but it means array[0..3] are undefined, is that OK?
// blah blah
let i = 2;
// Note that we could have an array bounds guard
if (i < array.length) {
  let t = array[i];  // Inferred type would be T!, but this is actually undefined :(
}

Object.defineProperty에도 문제가 있습니다.

let array = new Array(5)
Object.defineProperty(array, "length", 2, {
  get() { return 10 },
})

2015년 9월 9일 수요일 17:49 jods [email protected]에서 다음과 같이 썼습니다.

@impinball https://github.com/impinball 실제로 지도와 같은 최신 API,
forEach 또는 for..of는 이전에 없었던 요소를 건너뛰기 때문에 괜찮습니다.
초기화되거나 삭제되었습니다. (여기에는 다음으로 설정된 요소가 포함됩니다.
정의되지 않았지만 우리의 가설적인 null-safe TS는 그것을 금지합니다.)

그러나 고전적인 배열 액세스는 중요한 시나리오이며 다음을 수행하고 싶습니다.
이에 대한 좋은 솔루션을 참조하십시오. 제안한 대로 복잡한 분석을 수행하는 것은
사소한 경우를 제외하고는 분명히 불가능합니다.
그들은 일반적입니다). 그러나 내가 <
array.length 요소가 초기화되었음을 증명하지 않습니다.

다음 예를 생각해 보십시오. TS가 해야 할 일은 무엇입니까?

let 배열: T![] = []; // null이 아닌 정의되지 않은 빈 배열 T// blah blah
배열[4] = 새로운 T(); // array[4]는 괜찮지만 array[0..3]이 정의되지 않았음을 의미합니다. 괜찮습니까?// blah blahlet i = 2;// 배열 경계를 가질 수 있다는 점에 유의하세요.guardif (i < array. 길이) {
하자 t = 배열[i]; // 추론된 유형은 T!이지만 실제로는 정의되지 않습니다.
}

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/Microsoft/TypeScript/issues/185#issuecomment -139055786
.

다음 작업을 수행하기만 하면 됩니다.

1. Null 및 Undefined 유형을 참조 가능하게 만드십시오.
2. null 및 정의되지 않은 값을 무엇이든 할당할 수 없도록 합니다.
3. Null 허용 여부가 암시되는 경우 Null 및/또는 Undefined와 함께 공용체 유형을 사용합니다.

참으로 과감한 브레이킹 체인지이며 언어에 더 적합해 보입니다.
확대.
2015년 9월 10일 오전 9시 13분에 "Isiah Meadows" [email protected]에서 다음과 같이 썼습니다.

Object.defineProperty에도 문제가 있습니다.

let array = new Array(5)
Object.defineProperty(array, "length", 2, {
get() { return 10 },
})

2015년 9월 9일 수요일 17:49 jods [email protected]에서 다음과 같이 썼습니다.

@impinball https://github.com/impinball 실제로, 다음과 같은 최신 API는
지도,
forEach 또는 for..of는 이전에 없었던 요소를 건너뛰기 때문에 괜찮습니다.
초기화되거나 삭제되었습니다. (여기에는 다음으로 설정된 요소가 포함됩니다.
정의되지 않았지만 우리의 가설적인 null-safe TS는 그것을 금지합니다.)

그러나 고전적인 배열 액세스는 중요한 시나리오이며 다음을 수행하고 싶습니다.
이에 대한 좋은 솔루션을 참조하십시오. 제안한 대로 복잡한 분석을 수행하는 것은
사소한 경우를 제외하고는 분명히 불가능합니다.
그들은 일반적입니다). 그러나 내가 <
array.length 요소가 초기화되었음을 증명하지 않습니다.

다음 예를 생각해 보십시오. TS가 해야 할 일은 무엇입니까?

let 배열: T![] = []; // null이 아닌 정의되지 않은 빈 배열 T//
이러쿵 저러쿵
배열[4] = 새로운 T(); // array[4]는 괜찮지만 array[0..3]은
undefined, 괜찮나요?// blah blahlet i = 2;//
배열 경계 가드if (i < array.length) {
하자 t = 배열[i]; // 추론된 유형은 T!이지만 실제로는
찾으시는 주소가 없습니다 :(
}

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
<
https://github.com/Microsoft/TypeScript/issues/185#issuecomment-139055786>
.

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/Microsoft/TypeScript/issues/185#issuecomment -139230568
.

@impinball
나는 당신의 모범에 대해 괜찮다고 생각합니다. 이런 식으로 defineProperty 를 사용하는 것은 TS 안전 상자를 벗어나 동적 JS 영역으로 들어가는 것입니다. 그렇지 않나요? TS 코드에서 직접 defineProperty 호출한 적이 없는 것 같습니다.

@aleksey-bykov

언어 확장에 더 적합해 보입니다.

이 제안의 또 다른 문제는 널리 받아들여지지 않으면 가치가 떨어진다는 것입니다.
결국, 우리는 업데이트된 TS 정의가 필요하며 이것이 TS의 거의 사용되지 않거나, 호환되지 않거나, 확장되거나 분기되는 경우에는 발생하지 않을 것이라고 생각합니다.

IIRC가 던지기 때문에 유형이 지정된 배열에는 보증이 있다는 것을 알고 있습니다.
범위를 벗어난 배열 로드 및 저장에 대한 ReferenceError입니다. 일반 배열 및
인덱스가 범위를 벗어날 때 arguments 객체는 undefined를 반환합니다. 내
의견, 그것은 JS 언어 결함이지만 수정하는 것이 가장 확실합니다.
웹을 깨다.

이것을 "수정"하는 유일한 방법은 프록시를 반환하는 생성자를 통해 ES6에 있습니다.
및 해당 인스턴스 프로토타입 및 자체 프로토타입이 원래 Array로 설정됨
건설자. 이 같은:

Array = (function (A) {
  "use strict";
  function check(target, prop) {
    const i = +prop;
    if (prop != i) return target[prop];
    if (i >= target.length) {
      throw new ReferenceError();
    }
    return i;
  }

  function Array(...args) {
    return new Proxy(new Array(...args), {
      get(target, prop) {
        return target[check(target, prop)];
      },
      set(target, prop, value) {
        return target[check(target, prop)] = value;
      },
    });
  }

  Array.prototype = A.prototype;
  Array.prototype.constructor = Array
  Object.setPrototypeOf(Array, A);
  return Array;
})(Array);

(참고: 테스트되지 않았으며 전화로 입력했습니다...)

2015년 9월 10일 목요일 10:09 jods [email protected]에서 다음과 같이 작성했습니다.

@impinball https://github.com/impinball
나는 당신의 모범에 대해 괜찮다고 생각합니다. 이런 식으로 defineProperty를 사용하는 것은
TS 안전 상자를 벗어나 동적 JS 영역으로 들어가지 마십시오.
당신은 생각? TS 코드에서 직접 defineProperty를 호출한 적이 없다고 생각합니다.

@aleksey-bykov https://github.com/aleksey-bykov

언어 확장에 더 적합해 보입니다.

이 제안의 또 다른 문제는 널리 받아들여지지 않는 한
가치가 떨어졌습니다.
결국, 우리는 업데이트된 TS 정의가 필요하며 그럴 것이라고 생각하지 않습니다.
TS의 거의 사용되지 않거나, 호환되지 않거나, 확장되거나 분기되는 경우에 발생합니다.

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/Microsoft/TypeScript/issues/185#issuecomment -139245706
.

@impinball 처음에 "수정"할 것이 있는지 확실하지 않습니다...
그것들은 JS의 의미이고 TS는 어떻게든 그것들을 수용해야 합니다.

희소 배열과 비희소 배열을 선언하기 위해 (약간 다른) 마크업이 있고 희소 배열이 아닌 배열이 자동으로 초기화되도록 하면 어떻게 될까요(프로그래머가 초기화를 위한 값이나 방정식을 제공할 수 있음). 그렇게 하면 희소 배열이 T|undefined 유형이 되도록 강제할 수 있고(for... of 및 기타 '안전한' 작업을 사용하여 유형 T로 변경됨) 희소 배열이 아닌 배열의 유형은 그대로 둘 수 있습니다.

//not-sparse
var array = [arrlength] => index*3;
var array = <number[]>[3];
//sparse
var array = [];

분명히 이것은 최종 구문이 아닙니다.
두 번째 예는 모든 값을 해당 유형의 컴파일러 기본값으로 초기화합니다.
이것은 희소 배열이 아닌 경우 배열을 입력해야 함을 의미합니다. 그렇지 않으면 완전히 초기화된 후에 배열을 캐스트해야 할 것 같습니다.
또한 프로그래머가 배열을 non-sparse로 캐스팅할 수 있도록 배열에 대해 non-sparse 유형이 필요해야 합니다.

@그리포크
몰라요... 혼란스러워집니다.

그렇게 하면 희소 배열이 T|undefined 유형이 되도록 강제할 수 있습니다(for... of 및 기타 '안전한' 작업을 사용하여 유형 T로 변경됨).

JS의 단점 때문에 그런 식으로 작동하지 않습니다. let arr: (T|undefined)[] 가정합니다.
그래서 저는 arr[0] = undefined 있습니다.
그렇게하면 "안전한"기능을 사용하여 첫 번째 슬롯에 대해 undefined 를 반환합니다. 따라서 arr.forEach(x => ...) 에서는 x: T 라고 말할 수 없습니다. 여전히 x: T|undefined 이어야 합니다.

두 번째 예는 모든 값을 해당 유형의 컴파일러 기본값으로 초기화합니다.

이것은 정신이 그다지 TS와 같지 않습니다. 내가 틀릴 수도 있지만 TS 철학은 유형이 JS 상단의 추가 계층일 뿐이며 codegen에 영향을 미치지 않는다는 것입니다. 이것은 내가 별로 좋아하지 않는 부분적 유형 정확성을 위해 성능에 영향을 미칩니다.

TS는 분명히 JS의 모든 것으로부터 사용자를 보호할 수 없으며 유효한 TS에서 호출할 수 있는 몇 가지 함수/구조가 있습니다. 이 함수는 개체의 런타임 유형에 동적 영향을 미치고 정적 TS 유형 분석을 중단합니다.

이것이 유형 시스템의 구멍이라면 나쁠까요? 내 말은, 이 코드는 실제로 일반적이지 않습니다: let x: number[] = []; x[3] = 0; 그리고 그것이 당신이 하고 싶은 종류의 일이라면 배열을 let x: number?[] 선언해야 합니다.

완벽하지는 않지만 대부분의 실제 사용에 충분하다고 생각합니다. 만약 당신이 사운드 타입 시스템을 원하는 순수주의자라면, TS 타입 시스템은 어쨌든 사운드가 아니기 때문에 확실히 다른 언어를 살펴봐야 합니다. 어떻게 생각해?

그렇기 때문에 비희소 배열로 캐스팅하는 기능도 필요하다고 말씀드린 것입니다.
유형이므로 성능 없이 직접 배열을 초기화할 수 있습니다.
영향.
나는 희박한 것 사이의 구별에 만족할 것입니다.
유형별 배열 및 비희소 배열.

이것이 왜 중요한지 모르는 사람들을 위해, 그것은 당신이
T 와 T|null 사이의 차이를 원합니다.

2015년 9월 11일 금요일 오전 9시 11분에 jods [email protected]에서 다음과 같이 작성했습니다.

@Griffork https://github.com/Griffork
몰라요... 혼란스러워집니다.

그렇게 하면 희소 배열을 T|undefined 유형으로 강제할 수 있습니다(이는
for... of 및 기타 '안전한' 작업을 사용하여 유형 T로 변경)

JS의 단점 때문에 그런 식으로 작동하지 않습니다. 다음과 같이 가정합니다.
(|정의되지 않음)[].
그래서 저는 자유롭게 할 수 있습니다. arr[0] = undefined.
그렇게하면 "안전한"기능을 사용하여 _will_ undefined를 반환합니다.
첫 번째 슬롯의 경우. 따라서 arr.forEach(x => ...)에서 x: T라고 말할 수 없습니다.
여전히 x: T|undefined여야 합니다.

두 번째 예는 모든 값을 컴파일러 기본값으로 초기화합니다.
그 유형을 위해.

이것은 정신이 그다지 TS와 같지 않습니다. 어쩌면 내가 틀릴 수도 있지만 그것은 나에게 보인다
TS 철학은 유형이 JS 위에 추가된 레이어일 뿐이라는 것입니다.
그리고 그들은 codegen에 영향을 미치지 않습니다. 이것은 성능에 영향을 미칩니다.
내가 별로 좋아하지 않는 부분 유형 정확성.

TS는 분명히 JS의 모든 것으로부터 사용자를 보호할 수 없으며 다음이 있습니다.
유효한 TS에서 호출할 수 있는 여러 기능/구성
개체의 런타임 유형에 대한 동적 효과 및 정적 TS 중단
유형 분석.

이것이 유형 시스템의 구멍이라면 나쁠까요? 내 말은, 이 코드는
정말 흔하지 않습니다: let x: number[] = []; x[3] = 0; 그리고 그게 있다면
당신이하고 싶은 일의 종류는 아마도 당신의 배열을 선언해야 할 것입니다 let
x: 숫자?[].

완벽하지는 않지만 대부분의 실제 사용에 충분하다고 생각합니다.
사운드 유형 시스템을 원하는 순수주의자라면 반드시
TS형 시스템은 어쨌든 소리가 나지 않기 때문에 다른 언어를 보세요. 뭐
당신은 생각합니까?

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/Microsoft/TypeScript/issues/185#issuecomment -139408240
.

@jods4 내가 "수정"한다는 것은 JS 언어 설계 결함인 IMHO를 "수정"하는 것이었습니다. TypeScript가 아니라 _JavaScript 자체_에 있습니다.

@jods 저는 TS가 아니라 JS에 대해 불평하고 있습니다. 주제넘은거 인정합니다.

2015년 9월 10일 목요일 19:19 Griffork [email protected]에서 다음과 같이 썼습니다.

그렇기 때문에 비희소 배열로 캐스팅하는 기능도 필요하다고 말씀드린 것입니다.
유형이므로 성능 없이 직접 배열을 초기화할 수 있습니다.
영향.
나는 희박한 것 사이의 구별에 만족할 것입니다.
유형별 배열 및 비희소 배열.

이것이 왜 중요한지 모르는 사람들을 위해, 그것은 당신이
T 와 T|null 사이의 차이를 원합니다.

2015년 9월 11일 금요일 오전 9시 11분에 jods [email protected]에서 다음과 같이 작성했습니다.

@Griffork https://github.com/Griffork
몰라요... 혼란스러워집니다.

그렇게 하면 희소 배열을 T|undefined 유형으로 강제할 수 있습니다(이는
for... of 및 기타 '안전한' 작업을 사용하여 유형 T로 변경)

JS의 단점 때문에 그런 식으로 작동하지 않습니다. 다음과 같이 가정합니다.
(|정의되지 않음)[].
그래서 저는 자유롭게 할 수 있습니다. arr[0] = undefined.
그렇게하면 "안전한"기능을 사용하여 _will_ undefined를 반환합니다.
첫 번째 슬롯의 경우. 따라서 arr.forEach(x => ...)에서 x: T라고 말할 수 없습니다.
여전히 x: T|undefined여야 합니다.

두 번째 예는 모든 값을 컴파일러 기본값으로 초기화합니다.
그 유형을 위해.

이것은 정신이 그다지 TS와 같지 않습니다. 어쩌면 내가 틀릴 수도 있지만 그것은 나에게 보인다
그 TS 철학은 유형은
JS
그리고 그들은 codegen에 영향을 미치지 않습니다. 이것은 성능에 영향을 미칩니다.
내가 별로 좋아하지 않는 부분 유형 정확성.

TS는 분명히 JS의 모든 것으로부터 사용자를 보호할 수 없으며 다음이 있습니다.
유효한 TS에서 호출할 수 있는 여러 기능/구성
가지다
개체의 런타임 유형에 대한 동적 효과 및 정적 TS 중단
유형 분석.

이것이 유형 시스템의 구멍이라면 나쁠까요? 내 말은, 이 코드는
정말 흔하지 않습니다: let x: number[] = []; x[3] = 0; 그리고 그게 있다면
당신이하고 싶은 일의 종류는 아마도 당신의 배열을 선언해야 할 것입니다
허락하다
x: 숫자?[].

완벽하지는 않지만 대부분의 실제 사용에 충분하다고 생각합니다.
사운드 유형 시스템을 원하는 순수주의자라면 다음을 수행해야 합니다.
틀림없이
TS형 시스템은 어쨌든 소리가 나지 않기 때문에 다른 언어를 보세요.
뭐
당신은 생각합니까?

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
<
https://github.com/Microsoft/TypeScript/issues/185#issuecomment-139408240>
.

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/Microsoft/TypeScript/issues/185#issuecomment -139409349
.

그리고 배열 길이가 있는 내 명령문의 경우 모든 배열 액세스가 경계 내에 있고 경계를 벗어난 액세스는 인터페이스에 명시적으로 지정되지 않는 한 정의되지 않는다는 가정 하에 작업할 수 있습니다. 이는 C/C++가 하는 것과 매우 유사하며 누군가가 결국 언어 사양을 사용하지만 걱정하지 않는 타사 컴파일러를 작성하기로 결정한 경우 더 나은 타이핑과 잠재적으로 전체 컴파일러 최적화 부하를 모두 허용합니다. 방출을 일치시킵니다.

일치하는 C/C++ 정의되지 않은 동작을 지원하는 것이 표면적으로는 매우 어리석은 것처럼 들리지만 이 경우에는 그만한 가치가 있다고 생각합니다. 범위를 벗어난 액세스를 만들어 실제로 _더 나은_ 작업을 수행하는 것을 보는 것은 드뭅니다. 내가 본 사용 중 99.99%는 매우 자극적인 코드 냄새이며 거의 항상 JavaScript에 익숙하지 않은 사람들이 수행합니다.

(내 경험상 이 사람들 대부분은 TypeScript는 물론이고 CoffeeScript에 대해서도 들어본 적이 없습니다. 그들 중 많은 사람들은 막 완성되고 표준화된 ES2015의 새 버전인 JS조차 모르고 있습니다.)

이에 대한 새로운 해결책이 있습니까?

nullable이 아닌 유형을 사용하는 것 외에는 _assuredly_ null인 변수의 속성에 액세스하려고 하면 TypeScript가 실패하는 것이 여전히 유용해 보입니다.

var o = null;
console.log(o.x);

... 실패해야합니다.

모든 배열 액세스가 경계 검사되도록 유형 시스템을 통해 확인하는 것은 종속 유형의 영역으로 표류하는 것처럼 보입니다. 종속 유형은 꽤 깔끔하지만 null을 허용하지 않는 유형보다 훨씬 더 큰 기능인 것 같습니다.

컴파일 타임에 배열에 경계 검사가 적용되지 않는다고 가정하면 세 가지 옵션이 있는 것 같습니다.

1. 배열 인덱싱(및 인덱스에 의한 임의의 배열 요소 액세스)은 nullable이 아닌 형식의 배열에서도 nullable 형식을 반환하는 것으로 간주됩니다. 기본적으로 [] "method" 에는 T? 의 유형 서명이 있습니다. 경계 검사 인덱싱만 수행하고 있다는 것을 알고 있다면 애플리케이션 코드에서 T? 를 T! 로 캐스팅할 수 있습니다.
2. 배열 인덱싱은 배열의 일반 유형 매개변수와 정확히 동일한 유형(동일한 null 허용 여부 포함)을 반환하며 모든 배열 액세스는 애플리케이션에서 경계를 검사한다고 가정합니다. 범위를 벗어난 액세스는 undefined 반환하고 유형 검사기에 의해 포착되지 않습니다.
3. 핵 옵션: 모든 배열은 언어에 nullable로 하드코딩되어 있으며 nullable이 아닌 배열을 사용하려는 시도는 유형 검사에 실패합니다.

이것들은 모두 객체의 속성에 대한 인덱스 기반 액세스에도 적용됩니다. 예를 들어 object['property'] 여기서 object 는 { [ key: string ]: T! } 유형입니다.

개인적으로 배열이나 객체에 대한 인덱싱이 nullable 형식을 반환하는 첫 번째 옵션을 선호합니다. 그러나 두 번째 옵션조차도 현재 상황인 nullable인 모든 것보다 나은 것 같습니다. 핵 옵션은 총체적이지만 정직하게도 여전히 모든 것이 무효화되는 것보다 낫습니다.

유형이 기본적으로 null을 허용하지 않아야 하는지 또는 기본적으로 null을 허용해야 하는지에 대한 두 번째 질문이 있습니다. 두 경우 모두 제네릭을 처리하기 위해 명시적으로 nullable 및 명시적으로 non-nullable 형식 모두에 대한 구문을 갖는 것이 유용할 것 같습니다. 예를 들어 컨테이너 클래스(예: Map)에서 get 메서드를 상상해 보세요. 이 메서드는 _컨테이너에 null 허용이 아닌 값만 포함된 경우에도 일부 값을 취하고 유형을 반환할 수 있습니다.

class Container<K,V> {
  get(key: K): V? {
    // fetch from some internal data structure and return the value, if it exists
    // return null otherwise
  }
}

// only non-nullable values allowed in the container
const container = new Container<SomeKeyClass!, SomeValueClass!>();
const val: SomeValueClass!;
// ... later, we attempt to read from the container with a get() call
// even though only non-nullables are allowed in the container, the following should fail:
// get() explicitly returns null when the item can't be found
val = container.get(someKey);

유사하게, 우리는 (이것은 덜 강력한 인수임) 우리의 컨테이너 클래스가 nullable 키 유형을 사용하는 경우에도 삽입에서 null이 아닌 키만 허용하도록 하기를 원할 수 있습니다.

class Container<K, V> {
  insert(key: K!, val: V): void {
    // put the val in the data structure
    // the key must not be null here, even if K is elsewhere a nullable type
  }
}

const container = new Container<SomeKeyClass?, SomeValueClass>();
container.insert(null, new SomeValueClass()); // fails

따라서 기본 변경 여부에 관계없이 nullable 형식과 nullable이 아닌 형식 모두에 대해 명시적 구문을 사용하는 것이 유용할 것 같습니다. 내가 뭔가를 놓치고 있지 않는 한?

둘 다에 대한 구문이 있는 지점에서 기본값은 --noImplicitAny 와 유사한 컴파일러 플래그가 될 수 있는 것처럼 보입니다. 개인적으로 나는 2.0 릴리스까지 동일하게 유지되는 기본값에 투표하고 싶지만 탈출구가 있는 한(적어도 일시적으로) 아무 문제가 없어 보입니다.

나는 두 번째 옵션을 선호합니다. 비록 그것이 경계를 벗어난 액세스를 정의되지 않은 동작으로 만들더라도(TS 타이핑의 영역에서), 이것이 이에 대한 좋은 절충안이라고 생각합니다. 속도를 크게 높일 수 있으며 처리가 더 간단합니다. 범위를 벗어난 액세스가 가능하다고 예상하는 경우 명시적으로 nullable 형식을 사용하거나 결과를 nullable 형식으로 캐스팅해야 합니다(항상 가능함). 그리고 일반적으로 배열이 nullable이 아닌 경우 경계를 벗어난 액세스는 거의 항상 버그이며 어느 시점에서 격렬하게 분출해야 하는 버그입니다(JS 결함입니다).

프로그래머가 기대하는 바를 명시적으로 표현해야 합니다. 형식 안전성은 떨어지지만 이 경우 형식 안전성이 방해가 될 수 있다고 생각합니다.

다음은 합계 함수를 예로 사용하여 각 옵션을 비교한 것입니다(기본값이 가장 문제가 있음).

// Option 1
function sum(numbers: !number[]) {
  let res = 0
  for (let i = 0; i < numbers.length; i++) {
    res += <!number> numbers[i]
  }
  return res
}

// Option 2
function sum(numbers: !number[]) {
  let res = 0
  for (let i = 0; i < numbers.length; i++) {
    res += numbers[i]
  }
  return res
}

// Option 3
function sum(numbers: number[]) {
  let res = 0
  for (let i = 0; i < numbers.length; i++) {
    res += <!number> numbers[i]
  }
  return res
}

또 다른 예: map 함수.

// Option 1
function map<T>(list: !T[], f: (value: !T, index: !number) => !T): !T[] {
  let res: !T[] = []
  for (let i = 0; i < list.length; i++) {
    res.push(f(<!T> list[i], i));
  }
  return res
}

// Option 2
function map<T>(list: !T[], f: (value: !T, index: !number) => !T): !T[] {
  let res: !T[] = []
  for (let i = 0; i < list.length; i++) {
    res.push(f(list[i], i));
  }
  return res
}

// Option 3
function map<T>(list: T[], f: (value: !T, index: !number) => !T): T[] {
  let res: T[] = []
  for (let i = 0; i < list.length; i++) {
    const entry = list[i]
    if (entry !== undefined) {
      res.push(f(<!T> entry, i));
    }
  }
  return res
}

또 다른 질문: 각각의 entry 유형은 무엇입니까? !string , ?string 또는 string ?

declare const regularStrings: string[];
declare const nullableStrings: ?string[];
declare const nonnullableStrings: !string[];

for (const entry of regularStrings) { /* ... */  }
for (const entry of nullableStrings) { /* ... */  }
for (const entry of nonnullableStrings) { /* ... */  }

세 번째 옵션은 약간의 혀를 차는 듯한 제안이었습니다.stuck_out_tongue:

Re: 마지막 질문:

declare const regularStrings: string[];
declare const nullableStrings: string?[];
declare const nonNullableStrings: string![]; // fails typecheck in option three

for(const entry of regularStrings) {
  // option 1: entry is of type string?
  // option 2: depends on default nullability
}

for(const entry of nullableStrings) {
  // option 1 and 2: entry is of type string?
}

for(const entry of nonNullableStrings) {
  // option 1: entry is of type string?
  // option 2: entry is of type string!
}

예를 들어 nullable이 아닌 유형을 반환하려는 경우 배열에서 가져오는 경우 다른 곳에서 정의되지 않은 값이 없음을 보장한다고 가정하고 옵션 1을 사용하여 추가 캐스트를 수행해야 합니다. 배열에서 (이 보증의 요구 사항은 어떤 접근 방식을 취하든지 변경되지 않으며 as string! 됩니다.) 개인적으로 나는 더 명시적(암묵적으로 발생하는 것과 반대로 위험한 행동을 할 때 지정해야 함)과 대부분의 컨테이너 클래스 작동 방식에 더 일관성이 있기 때문에 여전히 선호합니다. 예를 들어 Map의 get 함수는 분명히 nullable 유형을 반환하고(키 아래에 개체가 있으면 개체를 반환하고, 없으면 null을 반환함) Map.prototype.get 가 nullable을 반환하면 object['property'] 는 아마도 다음을 수행해야 합니다. null 가능성에 대해 유사한 보장을 하고 유사하게 사용되기 때문에 동일합니다. 배열은 null 참조 오류가 다시 들어올 수 있고 임의 액세스가 유형 시스템에 의해 null을 허용하지 않도록 허용되는 이상한 배열로 남습니다.

확실히 다른 접근 방식이 있습니다. 예를 들어, 현재 Flow는 옵션 2를 사용 하고 마지막으로 SoundScript가 희소 배열을 해당 사양에서 명시적으로 불법으로 만드는지 확인 해당 배열을 불법으로 만들고 SoundScript는 새 규칙의 상위 집합입니다). 수동 길이 변경 및 초기 할당을 처리하는 방법을 여전히 파악해야 하지만 문제를 회피합니다. 나는 그들이 편리함 대 안전 절충안에서 옵션 1에 더 가까워질 것이라고 생각합니다. 즉, 쓰기가 덜 편리하지만 더 안전할 것입니다. 유형 시스템 건전성에 중점을 두기 때문이지만 아마도 다소 다르게 보일 것입니다. 희소 배열에 대한 금지로 인해 이러한 접근 방식보다

AFAIK TypeScript는 여기에서 어떤 선택에 대한 캐스트에 관계없이 동일한 JS를 계속 방출하고 기본 VM은 관계없이 후드 아래에서 경계 검사 어레이를 계속하기 때문에 이 시점에서 성능 측면은 매우 이론적이라고 생각합니다. 그래서 저는 그 주장에 그다지 흔들리지 않습니다. 내 마음에 대한 질문은 대부분 편의성 대 안전에 관한 것입니다. 나에게 여기에는 안전상의 이점이 편리함을 절충할 가치가 있는 것 같습니다. 물론, 둘 중 하나는 모든 유형이 nullable이 되도록 하는 것보다 개선된 것입니다.

성능 부분이 대부분 이론적이라는 데 동의하지만 여전히
가정의 편리함처럼. 대부분의 배열은 밀도가 높으며 null 허용 여부는
부울 및 숫자 배열에는 기본값이 의미가 없습니다. 그렇지 않은 경우
조밀한 배열로 의도된 경우 명시적으로 nullable로 표시되어야 하므로
의도는 분명하다.

TypeScript는 주장하는 방법이 정말 필요합니다.
다른 언어에서 정적 유형 검사를 지원하는 데 사용됩니다. 나는 에서 보았다
V8 코드 기반은 가정을 허용하는 UNREACHABLE(); 매크로입니다.
좀 더 안전하게, 불변량이 위반되면 프로그램을 충돌시킵니다. C++
유형 검사에 도움이 되는 정적 주장을 위한 static_assert 가 있습니다.

2015년 10월 20일 화요일 오전 4:01, Matt Baker 알림 @github.com
썼다:

옵션 3은 약간의 횡설수설한 제안이었습니다. [이미지:
:stuck_out_tongue:]

Re: 마지막 질문:

const regularStrings 선언: string[], const nullableStrings 선언: string?[], const nonNullableStrings 선언: string![]; // 옵션 3에서 유형 검사 실패
for(regularStrings의 const 항목) {
// 옵션 1: 항목이 문자열 유형입니까?
// 옵션 2: 기본 null 허용 여부에 따라 다릅니다.
}
for(nullableStrings의 const 항목) {
// 옵션 1과 2: 항목이 문자열 유형입니까?
}
for(nonNullableStrings의 const 항목) {
// 옵션 1: 항목이 문자열 유형입니까?
// 옵션 2: 항목이 문자열 유형입니다!
}

어떤 경우에는 - nullable이 아닌 유형을 반환하려는 경우
예를 들어 배열에서 가져오기 — 추가 캐스트를 수행해야 합니다.
옵션 1을 사용하면 다른 곳에서 정의되지 않은 항목이 없음을 보장한다고 가정합니다.
배열의 값(이 보증의 요구 사항은 변경되지 않습니다.
어떤 접근 방식을 취하든 상관없이 문자열로 입력하면 됩니다!).
개인적으로 나는 그것이 둘 다 더 명시적이기 때문에 여전히 그것을 선호합니다(당신은
위험할 수 있는 행동을 할 때 지정하십시오.
암시적으로 발생) 대부분의 컨테이너 클래스와 더 일관성이 있습니다.
작업: 예를 들어 Map의 get 함수는 분명히 nullable 유형을 반환합니다.
(키 아래에 객체가 있으면 객체를 반환하고, 없으면 null을 반환합니다),
Map.prototype.get이 nullable을 반환하면 object['property']
에 대해 비슷한 보증을 하기 때문에 아마 똑같이 해야 할 것입니다.
null 허용 여부와 유사하게 사용됩니다. 배열을 홀수로 남겨둡니다.
null 참조 오류가 다시 들어올 수 있는 위치와 임의 액세스가 있는 위치
유형 시스템에 의해 null이 허용되지 않습니다.

확실히 다른 접근 방식이 있습니다. 예를 들어, 현재 Flow는
옵션 2 http://flowtype.org/docs/nullable-types.html 및 마지막 I
확인된 SoundScript는 희소 배열을 사양에서 명시적으로 불법으로 만들었습니다.
https://github.com/rwaldron/tc39-notes/blob/master/es6/2015-01/JSExperimentalDirections.pdf
(음, 강력한 모드/"SaneScript"는 그것들을 불법으로 만들고 SoundScript는
새로운 규칙의 상위 집합), 이는 어느 정도 문제를 회피합니다.
수동 길이를 처리하는 방법을 알아내야 하지만
변경 및 초기 할당.

현재로서는 성능적인 측면이 지극히 이론적이라고 생각합니다만,
AFAIK TypeScript는 관계없이 동일한 JS를 계속 방출하기 때문에
여기에서 원하는 대로 캐스트하면 기본 VM이 계속됩니다.
상관없이 후드 아래의 경계 검사 배열. 그래서 나는 너무 휘둘리지 않는다.
그 주장. 내 마음에 대한 질문은 대부분 편의성 대
안전; 나에게 여기에는 안전상의 이점이 편리함을 절충할 가치가 있는 것 같습니다. 의
물론 어느 쪽이든 모든 유형이 nullable이 되도록 하는 것보다 개선된 것입니다.

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/Microsoft/TypeScript/issues/185#issuecomment -149468527
.

이사아 메도우즈

non-void 유형이라고 부르기 시작해야 합니까? 어쨌든 T! 또는 !T 로 non-void 를 명시적으로 정의하는 것은 실수라고 생각합니다. 사람이 읽기 어렵고 TypeScript 컴파일러의 모든 경우를 처리하는 것도 어렵습니다.

기본적으로 non-void 유형에서 볼 수 있는 주요 문제는 이것이 주요 변경 사항이라는 것입니다. Flow와 유사한 정적 분석을 추가하면 동작이 전혀 변경되지 않지만 더 많은 버그를 잡을 수 있습니까? 그러면 우리는 지금 이 클래스의 대부분 의 버그를 잡을 수 있지만 구문을 변경하지 마십시오. 앞으로는 크게 변경되지 않은 컴파일러 플래그 또는 기본 동작을 도입하는 것이 훨씬 더 쉬울 것입니다.

``` .ts
// 함수는 행복하게 컴파일됩니다.
함수 len(x: 문자열): 숫자 {
반환 x.길이;
}

len("작동"); // 5
len(널); // 오류, null 속성 길이 없음

``` .ts
function len(x: string): number {
    if (x === null) {
        return -1;
    }
    return x.length;
}

len("works"); // 5
len(null); // null

여기서 실제로 진행되는 것은 입력 데이터를 non-void 로 모델링하지만 함수에서 처리될 때 암시적으로 void 추가하는 것입니다. 마찬가지로 null 또는 undefined 명시적으로 반환할 수 없는 경우 반환 유형은 non-void undefined

?T 또는 T? 유형을 추가할 수도 있습니다. 이 유형은 사용 전에 null(및/또는 정의되지 않음) 검사를 강제 실행합니다. 개인적으로 T? 를 좋아하지만 Flow 와 함께 ?T 를 사용하는 선례가 있습니다.

``` .ts
함수 len(x: ?문자열): 숫자 {
반환 x.길이; // 오류: ?string 유형에 길이 속성이 없습니다. 유형 가드를 사용해야 합니다.
}

One more example -- what about using function results?

``` .js
function len(x: string): number {
    return x.length;
}

function identity(f: string): string {
    return f;
}

function unknown(): string {
    if (Math.random() > 0.5) {
        return null;
    }
    return "maybe";
}

len("works"); // 5
len(null); // error, no property length of null

identity("works"); // "works": string
identity(null); // null: void
unknown(); // ?string

len(identity("works")); // 5
len(identity(null)); // error, no property length of null
len(unknown()); // error: no length property on type ?string, you must use a type guard

내부적으로는 TypeScript가 null을 처리하는지 여부와 null 가능성이 있는 값이 제공되는지 여부를 확인하여 형식이 null일 수 있는지 여부를 유추하고 있다는 것입니다.

여기서 유일한 까다로운 부분은 정의 파일과 인터페이스하는 방법입니다. function(t: T) 선언하는 정의 파일이 두 번째 예와 마찬가지로 null/ void 검사를 수행한다고 기본적으로 가정하면 이 문제를 해결할 수 있다고 생각합니다. 이는 해당 함수가 컴파일러에서 오류를 생성하지 않고도 null 값을 사용할 수 있음을 의미합니다.

이제 두 가지를 허용합니다.

1. ?T 유형 구문의 점진적인 채택, 이 중 선택적 매개변수는 이미 교체되었습니다.
2. 앞으로 컴파일러 플래그 --noImplicitVoid 가 추가될 수 있으며 이는 선언 파일을 컴파일된 코드 파일과 동일하게 취급합니다. 이것은 "중단"일 수 있지만, 먼 길을 가면 대부분의 라이브러리는 유형이 void 및 T 때 ?T 를 사용하는 모범 사례를 채택합니다. 할 수 없을 때. 또한 옵트인이 되므로 사용하기로 선택한 사람들만 영향을 받습니다. 이것은 또한 개체가 무효일 수 있는 경우에 ?T 구문을 사용해야 할 수도 있습니다.

TypeScript에서 소스를 사용할 수 있을 때 훨씬 향상된 안전성을 제공하고 까다로운 문제를 찾는 동시에 정의 파일과 쉽고 상당히 직관적이며 이전 버전과 호환되는 통합을 허용하므로 이것이 현실적인 접근 방식이라고 생각합니다.

접두사 ? 변형은 IIRC 클로저 컴파일러 주석에서도 사용됩니다.

2015년 11월 17일 화요일 13:37 Tom Jacques [email protected]이 다음과 같이 썼습니다.

그냥 non-void 유형이라고 부르기 시작해야 합니까? 어쨌든 나는 생각한다.
T로 non-void를 명시적으로 정의합니다! 또는 !T는 실수입니다. 어렵네
인간으로서 읽기에, 또한 모든 경우를 다루기 어렵습니다.
타입스크립트 컴파일러.

기본적으로 void가 아닌 유형에서 볼 수 있는 주요 문제는
깨는 변화. 좀 더 정적 분석을 추가하면 어떻게 될까요?
Flow와 유사하지만 동작을 전혀 변경하지 않지만
더 많은 버그? 그러면 이제 이 클래스의 대부분의 버그를 잡을 수 있지만
구문을 변경하지 마십시오. 앞으로 훨씬 더 쉽게
덜 깨는 컴파일러 플래그 또는 기본 동작을 도입하십시오.
변화.

// 함수는 행복하게 컴파일합니다.function len(x: string): number {
반환 x.길이;
}

len("작동"); // 5
len(널); // 오류, null 속성 길이 없음

함수 len(x: 문자열): 숫자 {
if (x === null) {
반환 -1;
}
반환 x.길이;
}

len("작동"); // 5
len(널); // 없는

여기서 실제로 진행되는 것은 입력 데이터를 무효가 아닌 것으로 모델링하는 것입니다.
그러나 함수에서 처리될 때 암시적으로 void를 추가합니다. 비슷하게,
명시적으로 null을 반환하거나 반환할 수 없는 경우 반환 유형은 무효가 아닙니다.
찾으시는 주소가 없습니다

우리는 또한 ?T 또는 T를 추가할 수 있습니까? null(및/또는
undefined) 사용 전에 확인하십시오. 개인적으로 T?를 좋아하는데 선례가 있다
?T를 Flow와 함께 사용합니다.

함수 len(x: ?문자열): 숫자 {
반환 x.길이; // 오류: ?string 유형에 길이 속성이 없습니다. 유형 가드를 사용해야 합니다.
}

한 가지 더 예를 들어 -- 함수 결과를 사용하는 것은 어떻습니까?

함수 len(x: 문자열): 숫자 {
반환 x.길이;
}
함수 식별(f: 문자열): 문자열 {
리턴 f;
}
알 수 없는 함수(): 문자열 {
if (Math.random() > 0.5) {
null을 반환합니다.
}
"아마도"를 반환합니다.
}

len("작동"); // 5
len(널); // 오류, null 속성 길이 없음

신원("작동"); // "작동": 문자열
아이덴티티(null); // null: 무효
알려지지 않은(); // ?끈

len(identity("작동")); // 5
len(아이덴티티(널)); // 오류, null 속성 길이 없음
len(알 수 없음()); // 오류: ?string 유형에 길이 속성이 없습니다. 유형 가드를 사용해야 합니다.

내부에서 실제로 일어나고 있는 일은 TypeScript가
유형이 처리하는지 여부를 확인하여 유형이 null일 수 있는지 여부를 유추합니다.
null이며 null 가능성이 있는 값이 제공됩니다.

여기서 유일한 까다로운 부분은 정의 파일과 인터페이스하는 방법입니다. 나
기본적으로 다음과 같이 가정함으로써 해결할 수 있다고 생각하십시오.
함수(t: T)를 선언하는 정의 파일은 null/void 검사를 수행합니다.
두 번째 예처럼. 이는 해당 기능이
컴파일러가 오류를 생성하지 않는 null 값.

이제 두 가지를 허용합니다.

1. 선택 사항인 ?T 유형 구문의 점진적 채택
   매개변수는 이미 교체되었습니다.
2. 앞으로 컴파일러 플래그 --noImplicitVoid가 추가될 수 있습니다.
   선언 파일을 컴파일된 코드 파일과 동일하게 취급합니다. 이것
   "파괴"가 되겠지만, 먼 길을 따라가면 대부분의
   라이브러리는 유형이 가능한 경우 ?T를 사용하는 모범 사례를 채택합니다.
   void이고 T가 될 수 없는 경우입니다. 또한 옵트인이 되므로
   그것을 사용하기로 선택한 사람은 영향을 받을 것입니다.

훨씬 향상된 안전성을 제공하므로 이것이 현실적인 접근 방식이라고 생각합니다.
TypeScript에서 소스를 사용할 수 있을 때 까다로운 문제를 찾고,
여전히 쉽고, 상당히 직관적이며, 이전 버전과 호환 가능합니다.
정의 파일과의 통합.

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/Microsoft/TypeScript/issues/185#issuecomment -157463734
.

좋은 지적. 또한 기존의 선택적 매개변수 선언과 많은 유사점이 있습니다.

``` .ts
OptionalProperty {
o?: 문자열
}
VoidableProperty {
o: ?문자열
}

함수 withOptionalParam(o?: 문자열) { }
함수 withVoidableParam(o: ?string) { }
```

실제로 그들은 접두사를 사용합니다 . 명시적 nullable 형식에는 ? 를 사용하고 nullable이 아닌 형식에는 ! 를 사용하며 기본값은 nullable입니다.

voidable 대 nullable 구별은 많은 의미가 있습니다. :+1:

이 빙빙 도는 것 같아요.

무효화 가능/ 무효화 불가능 정의가 근본적인 문제를 해결하지 못하는 이유를 위에서 모두 읽었습니까?

@Griffork 모든 댓글을 읽었습니다. 내가 말한 것이 다른 사람들이 말한 것을 다소 재탕/조합한 것임을 인정하지만 그것이 앞으로 나아갈 가장 현실적인 길이라고 생각합니다. 나는 당신이 근본적인 문제로 보는 것이 무엇인지 모르지만 나에게 근본적인 문제는 null 및 undefined 가 모든 유형의 일부이고 컴파일러가 현재 시도할 때 안전을 보장하지 않는다는 것입니다. T 유형의 인수를 사용합니다. 내 예에 따라 :

``` .ts
함수 len(x: 문자열): 숫자 {
반환 x.길이;
}

len("작동");
// 오류 없음 -- 5

len(널);
// 컴파일러는 이것을 허용하지만 다음과 같은 오류가 발생해야 합니다.
// 오류: null의 '길이' 속성이 없습니다.

len(정의되지 않음);
// 컴파일러는 이것을 허용하지만 다음과 같은 오류가 발생해야 합니다.
// 오류: 정의되지 않은 '길이' 속성이 없습니다.
```

이것이 _언어_의 근본적인 문제인 안전 부족에 대한 나의 견해입니다. 정적 및 유형 분석을 사용하여 함수에 대한 인수의 흐름을 살펴보고 무언가가 안전하지 않게 수행될 수 있는 경우 오류를 표시하면 이 문제의 상당 부분을 해결할 수 있습니다. 코드를 사용할 수 있는 경우 해당 분석을 수행할 수 있기 때문에 ?T 유형이 전혀 필요하지 않습니다(모든 경우에 항상 정확하지는 않지만). ?T 유형을 추가하는 이유는 안전 점검을 강제하고 프로그래머의 의도를 매우 명확하게 해주기 때문입니다.

_implementation_의 문제는 이전 버전과의 호환성입니다. TS 팀이 현재 T 유형이 기본적으로 무효가 아닌 변경 사항을 내일 릴리스하면 해당 유형 서명으로 현재 무효 입력을 수락하고 처리하는 기존 코드가 중단됩니다. TS 팀 구성원은 바로 이 문제에서 그렇게 큰 변경을 가할 의사가 없다고 밝혔습니다. 그들은 효과가 충분히 작고 이익이 충분히 크면 어떤 것을 기꺼이 깨뜨릴 것입니다. 그러나 이것은 너무 큰 영향을 미칠 것입니다.

제 제안은 두 부분으로 나뉘는데, 그 중 하나는 실제 버그를 찾는 것 외에는 기존 구문/의미를 변경하지 않는 언어에 대한 훌륭한 추가 사항이고 다른 하나는 오류의 영향을 줄이는 가능한 방법입니다. 미래에 non-void 유형에 대한 더 강력한 보장을 얻기 위해 변경 사항을 깨뜨렸습니다. 여전히 획기적인 변경이지만 더 수용 가능한 크기와 특성을 갖기를 바랍니다.

1부:

• null/undefined/void 유형을 처리하지 않는 함수에 전달할 수 있는 경우를 식별하는 분석을 추가합니다(TS 코드가 있는 경우에만 작동하며 정의 파일에는 없음).
• 인수를 사용하기 전에 무효 확인을 강제하는 ?T 유형을 추가하십시오. 이것은 실제로 언어 수준 옵션 유형에 대한 구문상의 설탕입니다.
• 이 두 기능은 각각 고유한 장점이 있으므로 독립적으로 구현할 수 있습니다.

두 번째 부분:

• 기다리다. 나중에 1부가 소개되고 TS의 커뮤니티와 사용자가 이러한 기능을 사용할 시간이 생긴 후 표준은 유형이 null이 아닐 때 T 를 사용하고 ?T 유형이 null일 수 있는 경우. 이것이 보장되지는 않지만 이것이 분명한 모범 사례가 될 것이라고 생각합니다.
• 별도의 기능으로 컴파일러 옵션 --noImplicitVoid 을 추가합니다. 이 옵션을 사용하면 형식이 무효가 될 수 있는 경우 ?T 가 되어야 합니다. 이것은 이미 존재하는 모범 사례를 시행하는 컴파일러일 뿐입니다. 모범 사례를 따르지 않는 정의 파일이 있으면 올바르지 않지만 이것이 옵트인인 이유입니다.
• 당신이 정말로 엄격하기를 원한다면, 플래그는 그것이 적용되어야 하는 디렉토리/파일을 지정하는 인수를 받아들일 수 있습니다. 그런 다음 변경 사항을 코드에만 적용하고 node_modules 제외할 수 있습니다.

2부가 없어도 1부가 가능하기 때문에 가장 현실적인 선택이라고 생각한다. 여전히 이 문제를 크게 완화할 수 있는 좋은 기능입니다. 물론 완벽하지는 않지만 일어날 수 있다는 의미라면 충분히 받아들일 것입니다. 또한 미래에 null이 아닌 실제 유형에 대한 옵션을 테이블에 남겨둡니다. 현재 문제는 이 문제가 오래 지속될수록 TS에 작성 중인 코드가 더 많기 때문에 이를 수정하기 위한 주요 변경 사항이 더 많다는 것입니다. 1부에서는 최악의 경우 그 속도를 극적으로 늦추고 기껏해야 시간이 지남에 따라 영향을 줄여야 합니다.

@tejacques 저는 이에 전적으로

@tejacques - FWIW, 귀하의 평가 및 제안에 전적으로 동의합니다. TS 팀이 동의하기를 바랍니다. :)

사실 두 가지:

첫째, 1부에서 언급한 Flow와 같은 분석이 필요한지 잘 모르겠습니다. 매우 멋지고 유용하지만, voidable/ ?T 유형을 유지하고 싶지는 않습니다. 이 유형은 언어의 현재 디자인에서 훨씬 더 실현 가능하고 훨씬 더 장기적인 가치를 제공합니다.

또한 --noImplicitVoid 를 조금 다르게 표현하겠습니다. "유형을 다음과 같이 요구하는 대신 무효화 불가능한(즉, 기본) 유형에 null 및 undefined 를 할당하는 것을 허용하지 않습니다. 무효화될 수 있는 경우 ?T ". 나는 우리가 의미론 만 같은 것을 의미한다고 확신합니다. TS가 작동하는 방식을 이해하는 경우 실제로 시행할 수 있는 유일한 것인 정의보다는 사용법에 중점을 둡니다.

그리고 지금 막 떠오른 것이 있습니다. 그러면 4가지 수준의 무효화 가능성이 있습니다(이는 Flow에서도 마찬가지이며, 이 대화에서 많은 영감을 주고 있다고 생각합니다).

interface Foo {
  w: string;
  x?: string;
  y: ?string;
  z?: ?string;
}

--noImplicitVoid 에서 w 는 유효한 문자열만 될 수 있습니다. 이것은 유형 안전에 대한 큰 승리입니다. 안녕, 10억 달러의 실수! 물론 --noImplicitVoid 없으면 유일한 제약 조건은 지정해야 하지만 null이거나 정의되지 않을 수 있다는 것입니다. 이것은 언어의 다소 위험한 행동입니다. 왜냐하면 그것이 실제보다 더 많은 것을 보장하는 것처럼 보이기 때문입니다.

x 은 현재 설정에서 완전히 관대합니다. 그것은 string, null, undefined일 수 있으며 그것을 구현하는 객체에 존재할 필요조차 없습니다. --noImplicitVoid 에서는 상황이 조금 더 복잡해집니다... 정의하지 않을 수도 있지만, 무언가를 설정하면 무효가 될 수 없습니까? Flow가 이것을 처리하는 방식은 x 를 undefined (비존재를 모방)로 설정할 수 있지만 null 는 설정할 수 없다는 것입니다. 그러나 이것은 TypeScript에 대해 너무 독단적일 수 있습니다.

또한 x 를 사용하기 전에 무효 확인을 요구하는 것이 논리적으로 이해가 되지만, 이는 역시 획기적인 변경이 될 것입니다. 이 동작이 --noImplicitVoid 플래그의 일부일 수 있습니까?

y 는 임의의 문자열 또는 무효 값으로 설정할 수 있지만 _반드시_ 무효일지라도 어떤 형태로든 존재해야 합니다. 물론 액세스하려면 무효 확인이 필요합니다. 이 동작은 약간 의외일 수 있습니다. undefined 로 설정하는 것과 동일하게 설정하는 것을 _not_ 고려해야 합니까? 그렇다면 무효 수표를 요구하는 것을 제외하고 x 와 다른 점은 무엇입니까?

마지막으로 z 는 지정할 필요가 없으며 절대적으로 무엇이든 설정할 수 있으며(물론 문자열이 아닌 경우는 제외) 액세스하기 전에 무효 검사가 필요합니다. 모든 것이 여기에서 의미가 있습니다!

x 와 y 사이에는 약간의 겹침이 있으며 x x 는 결국 커뮤니티에서 더 이상 사용되지 않으며 최대한의 안전을 위해 z 형식을 선호합니다. .

@tejacques

분석이 수행될 수 있기 때문에 코드를 사용할 수 있을 때 ?T 유형이 전혀 필요하지 않습니다(모든 경우에 항상 완벽하게 정확하지는 않지만).

이 진술은 올바르지 않습니다. 전체 코드 소스를 사용할 수 있는 경우에도 null 허용 여부의 많은 측면을 설명할 수 없습니다.

예를 들어, 인터페이스를 (정적으로) 호출할 때 인터페이스가 그에 따라 주석 처리되지 않은 경우 null 전달이 괜찮은지 여부를 알 수 없습니다. TS와 같은 구조적 유형 시스템에서는 어떤 객체가 인터페이스의 구현이고 어떤 객체가 아닌지 알기조차 쉽지 않습니다. 일반적으로 신경 쓰지 않지만 소스 코드에서 null 허용 여부를 추론하려면 그렇게 하면 됩니다.

또 다른 예: list 배열과 null 인수를 허용하지 않는 소스 코드를 가진 함수 unsafe(x) 있는 경우 컴파일러는 다음과 같이 말할 수 없습니다. 라인이 안전한지 여부: list.filter(unsafe) . 그리고 실제로 list 의 가능한 모든 내용이 무엇인지 정적으로 알 수 없다면 이것은 수행할 수 없습니다.

다른 경우는 상속 등에 연결됩니다.

null 계약의 노골적인 위반을 표시하는 코드 분석 도구가 가치가 없다는 말은 아닙니다. 소스 코드를 사용할 수 있을 때 null 주석의 유용성을 경시하는 것은 IMHO 오류라는 것을 지적하고 있습니다.

나는 null 허용 여부에 대한 추론이 많은 간단한 경우에 이전 버전과의 호환성을 줄이는 데 도움이 될 수 있다고 생각한다고 이 토론의 어딘가에서 말한 적이 있습니다. 그러나 소스 주석을 완전히 대체할 수는 없습니다.

@tejacques 내 나쁜, 나는 당신의 의견을 잘못 읽었습니다 (어떤 이유로 내 두뇌가 void===null 결정했습니다 :(나는 단지 잠에서 깨어난 탓입니다).
그래도 추가 게시물을 주셔서 감사합니다. 원래 게시물보다 훨씬 더 이해가 되었습니다. 나는 사실 그 아이디어를 꽤 좋아한다.

하나의 글에 쓰는건 읽을 수 없는 덩어리라 셋이서 따로 답장을 드리겠습니다.

@Griffor 문제 없습니다. 때로는 텍스트로 모든 것을 제대로 전달하기가 어렵고 어쨌든 명확히 할 가치가 있다고 생각합니다.

@dallonf 당신의 표현은 정확히 내가 의미하는 바입니다. 우리는 같은 페이지에 있습니다.

x?: T 와 y: ?T 의 차이점은 툴팁/함수 사용법과 사용된 타이핑 및 가드에 있다고 생각합니다.

선택적 인수로 선언하면 도구 설명/함수 사용법이 변경되어 선택 사항임을 분명히 알 수 있습니다.
a?: T 는 함수 호출에서 인수로 전달할 필요가 없으며 비워 둘 수 있습니다.
선언에 ?: 가 없으면 함수 호출에서 인수로 전달되어야 하며 비워 둘 수 없습니다.

w: T 는 void 아닌 필수 인수입니다( --noImplicitVoid ).
경비원이 필요하지 않습니다

x?: T 는 선택적 인수이므로 유형은 실제로 T | undefined
if (typeof x !== 'undefined') 경비원이 필요합니다.
트리플 그래프 참고 !== 에 정확한 검사를위한 undefined .

y: ?T 는 필수 인수이며 유형은 실제로 T | void
if (y == null) 경비원이 필요합니다.
null 및 undefined 즉 void 모두와 일치하는 이중 문자 == 주목하십시오.

z?: ?T 선택적 인수이며, 종류는 정말 T | undefined | void 이는 T | void
if (z == null) 경비원이 필요합니다.
null 및 undefined 즉 void 모두와 일치하는 이중 문자 == 다시 주목하십시오.

모든 선택적 인수와 마찬가지로 선택적 인수 뒤에 오는 필수 인수를 가질 수 없습니다. 그래서 차이가 있을 것입니다. 이제 선택적 인수에 대해 null 가드를 수행할 수도 있고 그것도 작동하지만 주요 차이점은 다음과 같은 경우 null 값을 함수에 전달할 수 없다는 것입니다. 를 호출; 그러나 undefined 전달할 수 있습니다.

이 모든 것이 실제로 자리가 있다고 생각하므로 현재 선택적 인수 구문을 반드시 사용하지 않을 것이지만 z 형식이 가장 안전하다는 데 동의합니다.

편집: 문구를 업데이트하고 일부 오타를 수정했습니다.

@jods4 나는 당신이 말한 모든 것에 거의 동의합니다. 나는 void 가 아닌 타이핑의 중요성을 경시하려는 것이 아닙니다. 한 번에 한 단계씩 밀어붙이려고 합니다. TS 팀이 나중에 할 수 없다면 적어도 우리는 더 나은 상태이며 더 많은 검사와 ?T 를 구현한 후 나중에 할 수 있다면 임무가 완료된 것입니다.

Arrays 는 참으로 까다롭다고 생각합니다. 항상 다음과 같이 할 수 있습니다.

``` .ts
함수 numToString(x: 숫자) {
반환 x.toString();
}
var 숫자: number[] = Array(100);
numToString(숫자[0]); // 망했어!

You can try to do something specifically for uninitialized arrays, like typing the `Array` function as `Array<?T>` / `?T[]` and upgrading it to `T[]` after a for-loop initializing it, but I agree that you can't catch everything. That said, that's already a problem anyway, and arrays typically don't even send uninitialized values to `map`/`filter`/`forEach`.

Here's an example -- the output is the same on Node/Chrome/IE/FF/Safari.

``` .ts
function timesTwo(x: number) {
    return x * 2;
}
function all(x) {
    return true;
}
var nums: number[] = Array(100);
nums.map(timesTwo);
// [undefined x 100]
nums.filter(all);
// []
nums.forEach(function(x) { console.log(x); })
// No output

그것은 예상치 못한 일이기 때문에 그다지 도움이 되지는 않지만 오늘날 실제 JavaScript의 오류는 아닙니다.

내가 강조하고 싶은 유일한 다른 점은 인터페이스로도 발전할 수 있다는 것입니다. 유형 시스템을 통하는 것보다 정적 분석을 통해 훨씬 더 많은 작업과 노력을 들일 뿐이지만 이미 지금 일어나고 있는 일과 크게 다르지는 않습니다.

여기 예가 있습니다. --noImplicitVoid 가 꺼져 있다고 가정해 보겠습니다.

``` .ts
인터페이스 ITransform{
(x: T): U;
}

인터페이스 IHaveName {
이름: 문자열;
}

함수 변환(x: T, fn: ITransform) {
반환 fn(x);
}

var 이름 = {
이름: "푸"
};

var 잘못된 이름 = {
이름: 1234
};

var 이름이 널 = {
이름: null
};

var someFun = (x: IHaveName) => x.name;
var someFunHandlesVoid = (x: IHaveName) => {
if (x != null && x.name != null) {
x.name을 반환합니다.
}
"이름 없음"을 반환합니다.
};

All of the above code compiles just fine -- no issues. Now let's try using it

``` .ts
someFun(named);
// "Foo"
someFun(wrongName);
// error TS2345: Argument of type '{ name: number; }' is not assignable to parameter
// of type 'IHaveName'.
//   Types of property 'name' are incompatible.
//     Type 'number' is not assignable to type 'string'.
someFun(null);
// Not currently an error, but would be something like this:
// error TS#: Argument of type 'null' is not assignale to parameter of type 'IHaveName'.
someFun(namedNull);
// Not currently an error, but would be something like this:
// error TS#: Argument of type '{ name: null; }' is not assignable to parameter of
// type 'IHaveName'.
//   Types of property 'name' are incompatible.
//     Type 'null' is not assignable to type 'string'.

someFunHandlesVoid(named);
// "Foo"
someFunHandlesVoid(wrongName);
// error TS2345: Argument of type '{ name: number; }' is not assignable to parameter
// of type 'IHaveName'.
someFunHandlesVoid(null);
// "No Name"
someFunHandlesVoid(namedNull);
// "No Name"

transform(named, someFun);
// "Foo"
transform(wrongName, someFun);
// error TS2453: The type argument for type parameter 'T' cannot be inferred from the usage.
// Consider specifying the type arguments explicitly.
//   Type argument candidate '{ name: number; }' is not a valid type argument because it
//   is not a supertype of candidate 'IHaveName'.
//     Types of property 'name' are incompatible.
//       Type 'string' is not assignable to type 'number'.
transform(null, someFun);
// Not currently an error, but would be something like this:
// error TS#: The type argument for type parameter 'T' cannot be inferred from the usage.
// Consider specifying the type arguments explicitly.
//   Type argument candidate 'null' is not a valid type argument because it
//   is not a supertype of candidate 'IHaveName'.
transform(namedNull, someFun);
// Not currently an error, but would be something like this:
// error TS#: The type argument for type parameter 'T' cannot be inferred from the usage.
// Consider specifying the type arguments explicitly.
//   Type argument candidate '{ name: null; }' is not a valid type argument because it
//   is not a supertype of candidate 'IHaveName'.
//     Types of property 'name' are incompatible.
//       Type 'string' is not assignable to type 'null'.

transform(named, someFunHandlesVoid);
// "Foo"
transform(wrongName, someFunHandlesVoid);
// error TS2453: The type argument for type parameter 'T' cannot be inferred from the usage.
// Consider specifying the type arguments explicitly.
//   Type argument candidate '{ name: number; }' is not a valid type argument because it
//   is not a supertype of candidate 'IHaveName'.
transform(null, someFunHandlesVoid);
// "No Name"
transform(namedNull, someFunHandlesVoid);
// "No Name"

모든 것을 잡을 수는 없지만 많은 것을 잡을 수 있다는 것은 맞습니다.

마지막 참고 사항 -- --noImplicitVoid 가 켜져 있을 때 위의 동작은 무엇이어야 합니까?

이제 someFun 및 someFunHandlesVoid 는 모두 동일하게 유형 검사되고 someFun 생성한 것과 동일한 오류 메시지를 생성합니다. someFunHandlesVoid 가 void 를 처리하더라도 null 또는 undefined 를 사용하여 호출하면 오류가 발생합니다. 서명에는 void 가 필요하지 않기 때문입니다. null 또는 undefined 를 수락하려면 (x: ?IHaveName) : string 로 입력해야 합니다. 유형을 변경하면 이전과 같이 계속 작동합니다.

이것은 브레이킹 체인지 부분이지만, 그것을 수정하기 위해 해야 할 일은 타입 서명에 단일 문자 ? 를 추가하는 것입니다. 우리는 경고와 같은 일을 하는 또 다른 플래그 --warnImplicitVoid 를 가질 수 있으므로 천천히 마이그레이션할 수 있습니다.

이 일을 하는 것이 완전히 바보 같은 느낌이 들지만, 나는 하나의 포스트를 더 만들 것입니다.

이 시점에서 진행하려면 어떻게 해야 할지 잘 모르겠습니다. 더 나은 아이디어가 있습니까? 우리는:

• 이것이 어떻게 작동해야 하는지 계속 논의/명시하시겠습니까?
• 이것을 세 가지 새로운 기능 제안으로 바꾸시겠습니까?
  
  
  
  • 향상된 분석
  
  
  • 미정/옵션 유형 ?T
  
  
  • --noImplicitVoid 컴파일러 옵션
  
  
• 입력을 위해 TypeScript 팀원을 핑하시겠습니까?

나는 TypeScript 팀에 이 스레드가 얼마나 긴지 고려하여 이 스레드를 따라잡으라고 요청하는 것은 거의 비인간적이기 때문에 새로운 제안에 기대고 거기에서 계속 논의하고 있습니다.

@tejacques

• dallonf에 대한 삼중 같음 예에서 typeof 가 누락되었습니다.
• jods4에 대한 예제에서 일부 ? 가 누락된 것 같습니다.

내용이 이 스레드에 있어야 한다고 생각하는 만큼 이 스레드는 더 이상 "감시"되지 않는다고 생각합니다(가끔 쳐다보는 것과 비슷할 수 있음). 따라서 몇 가지 새로운 스레드를 만드는 것은 확실히 견인력을 구축할 것입니다.
그러나 사람들이 머리를 들고 피드백을 먼저 제공할 때까지 며칠/일주일을 기다리십시오. 당신은 당신의 제안이 꽤 견고하기를 원할 것입니다.

편집: 기억된 마크다운이 존재합니다.

이 스레드에 대한 코멘트는 현 단계에서 매우 무의미합니다. TypeScript 팀이 수용할 수 있다고 생각하는 제안이 만들어지더라도(나는 8월에 이것을 시도했습니다) 소음 속에서 찾을 수 있는 방법은 없습니다.

당신이 기대할 수 있는 최선은 주의 수준이 TypeScript 팀이 자신의 제안을 제시하고 구현하기에 충분하다는 것입니다. 그렇지 않으면 잊어 버리고 Flow를 사용하십시오.

이것을 분할하는 데 +1이 있지만 현재로서는 --noImplicitVoid 옵션이
nullable 형식이 구현될 때까지 기다립니다.

지금까지 우리는 대부분의 구문과 의미에 동의했습니다.
nullable 유형이므로 누군가 제안 및 구현을 작성할 수 있다면
그 중 황금이 될 것입니다. 비슷한 절차에서 제안을 받았습니다.
다른 유형의 열거형에 대해서는
다른 프로젝트로 인해 구현하십시오.

2015년 11월 18일 수요일 21:24 Tom Jacques [email protected]이 다음과 같이 썼습니다.

이거 하기엔 완전 바보같은 느낌이 들지만 하나 더 만들게
게시하다.

이 시점에서 진행하려면 어떻게 해야 할지 잘 모르겠습니다. 더 나은 아이디어가 있습니까?
우리는:

• 이것이 어떻게 작동해야 하는지 계속 논의/명시하시겠습니까?
• 이것을 세 가지 새로운 기능 제안으로 바꾸시겠습니까?
  
  
  
  • 향상된 분석
  
  
  • 아마도/옵션 유형 ?T
  
  
  • --noImplicitVoid 컴파일러 옵션
  
  
• 입력을 위해 TypeScript 팀원을 핑하시겠습니까?

나는 새로운 제안에 대해 기대하고 있으며 그 이후로 계속 토론하고 있습니다.
TypeScript 팀에 이 스레드를 따라잡으라고 요청하는 것은 거의 비인간적입니다.
기간을 고려합니다.

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/Microsoft/TypeScript/issues/185#issuecomment -157928828
.

--noImplicitNull 옵션에 대해 +1(무효 및 null 할당 허용 안 함).

특수 유형 Op<A> = A | NullType 사용하여 이 문제를 완화하려고 했습니다. 꽤 잘 작동하는 것 같습니다. 여기를 참조

_--noImplicitNull_도 +1:+1:

--noImplicitNull의 경우 +1

닫혀야 하나요?

@Gaelan Given #7140이 병합되었습니다. 여기 몇 사람이 제안한 대로 --noImplicitNull 대한 새로운 전용 문제를 제출하려면 지금 그렇게 하는 것이 안전할 것입니다.

@isiahmeadows 그러면 이것을 열어 두는 것이 더 나을 것입니다.

닫혀야 하나요?

https://github.com/Microsoft/TypeScript/issues/2388 이 이 작업의 이름 변경 부분이라고 생각합니다. 이것이 우리가 아직 이 기능을 완료했다고 선언하지 않은 이유입니다.

여기 몇 사람이 제안한 대로 --noImplicitNull 대한 새로운 전용 문제를 제출하려면 지금 하는 것이 안전할 것입니다.

이 새 플래그의 요청된 의미를 이해하지 못합니다. 나는 명확한 제안으로 새로운 문제를 여는 것이 좋습니다.

@mhegazy 이번 호 앞부분에서 --noImplicitNull 에 대해 제안한 아이디어는 모든 것이 명시적으로 ?Type 또는 !Type 여야 한다는 것이었습니다. IMHO 기본적으로 nullable이 아닌 유형 자체가 있을 때 IIRC가 이미 구현되었다는 다른 플래그가 있는 경우 상용구의 가치가 없다고 생각합니다.

#7140과 #8010이 모두 병합되어 이제 종료합니다.

마감된 이슈에 대해 댓글을 달면 죄송합니다. 하지만 어디에 물어볼 수 있는 더 좋은 곳이 없고 관심이 없다면 새로운 이슈가 될 가치가 없다고 생각합니다.
파일별로 암시적 null을 처리하는 것이 가능합니까?
예를 들어, noImplicitNull을 사용하여 많은 td 파일을 처리하지만(그들은 확실히 유형이 지정되어 있고 그런 식으로 생각되었기 때문에) 내 소스를 implicitNull로 처리합니까?
아무도 이것을 유용하게 생각할까요?

@massimiliano-mantione, https://github.com/Microsoft/TypeScript/issues/8405 를 참조