왜 && 오퍼레이터가 두 번째 피연산자의 유형을 생성하는가?

왜 && 오퍼레이터가 두 번째 피연산자의 유형을 생성하는가?

TypeScript 규격은 제4.15.6조에 다음과 같이 기술되어 있다.&&연산자:

운영자는 피연산자를 어떤 유형이든 허용하고 두 번째 피연산자와 동일한 유형의 결과를 산출한다.

Javascript에서&&운영자는 첫 번째 피연산자가 거짓이면 반환하고, 그렇지 않으면 두 번째 피연산자를 반환한다(ECMA-262 §11.11 참조).

즉, 왼쪽 피연산자가 위작일 경우&&왼쪽 피연산자의 유형과 일치하는 값을 반환한다.예를 들어,

typeof ( false && {}      ) === "boolean" // true
typeof ( ''    && 1       ) === "string"  // true
typeof ( null  && "hello" ) === "object"  // true
typeof ( NaN   && true    ) === "number"  // true

위에서 인용한 규칙에 따라 형식 지정은 위 식의 유형을 잘못 예측할 수 있다.Object,Number,String그리고Boolean각각,

내가 뭘 빼놓았나요?A의 활자를 만들 만한 충분한 이유가 있는가.&&표현은 두 번째 피연산자의 유형과 일치하는가?결과 유형은 다음과 같이 행동해야하지 않을까?||연산자, 그리고 두 피연산자의 가장 일반적인 유형을 반환한다.Any만약 가장 흔한 타입이 없다면?

요컨대, 여기에는 모두를 기쁘게 하는 해결책이 없다.

다음과 같은 일반적인 관용구를 생각해 보십시오.

var customer = GetCustomer(...); // of type 'Customer'
var address = customer && customer.address;
if(address) {
    printAddressLabel(address); // Signature: (Address) => void
} else {
    // Couldn't find the customer or the customer has no address on file
}

고객과 주소 사이에 가장 일반적인 유형이 없기 때문에 '주소'를 포기하고 '임의'라고 결정하는 것은 꽤 궁색할 것이다.

대부분의 경우, && 오퍼레이터를 사용하는 경우, 유형이 이미 일치하거나, 위와 같이 가치 결합 방식으로 사용되고 있다.어느 경우든 오른쪽 피연산자의 유형을 반환하면 사용자에게 예상 유형을 제공한다.

형식 안전이 기술적으로 현시점에서 무너지고 있지만, 오류가 발생할 가능성이 있는 방법으로는 그렇게 하지 않고 있다.결과 값을 진실에 대해 테스트하거나(이 경우 유형이 다소 관련이 없는 경우), 추정적 우측 피연산자를 일부 작업에 사용(위의 두 가지 작업을 모두 수행하는 예)할 수 있다.

만약 우리가 당신이 열거한 예들을 보고 왼쪽 피연산자가 불분명한 트루티나 거짓인 척하고 나서 반환가치에 작용하는 온전한 코드를 쓰려고 하면, 그것은 훨씬 더 명확해진다. '거짓 &&}'으로 당신은 이미 '아무런' 논쟁 위치나 진실성 테스트에 들어가지 않고 있다.

---

부록

위와 같은 것에 대해 납득이 가지 않는 사람도 있었으므로, 여기에 다른 설명이 있다.

TypeScript 유형 시스템에 다음과 같은 세 가지 유형이 추가된 것으로 잠시 가정해 봅시다.Truthy<T>Falsy<T>그리고Maybe<T> .T과 같다 이러한 유형의 규칙은 다음과 같다.

1. Truthy<T> 닮았다 똑같이 행동하다T
2. 의 속성에 액세스할 수 없는 경우Falsy<T>
3. Maybe<T>, 에서 조건으로 사용될 때if,이 되다, 가 되다Truthy<T>그것과 같은 체내에서.if막아서Falsy<T>에서else막다

이렇게 하면 다음과 같은 일을 할 수 있다.

function fn(x: Maybe<Customer>) {
   if(x) {
      console.log(x.address); // OK
   } else {
      console.log(x.phone); // Error: x is definitely falsy
   }
   console.log(x.name); // Warning: x might be falsy!
}

아직까지는 꽤 괜찮다.이제 우리는 그 &&& 오퍼레이터의 유형 규칙이 무엇인지 알아낼 수 있다.

• Truthy<T> && x오류일 것이다 - 만약 왼쪽이 트루티하다고 알려져 있다면, 당신은 그냥 글을 썼어야 한다.x
• Falsy<T> && x오류가 있어야 한다 - 왼쪽이 거짓인 것으로 알려지면,x연결할 수 없는 코드
• Maybe<T> && x...을 생산해야 한다.뭐?

우리는 의 결과를 안다.Maybe<T> && x유형의 거짓 값이 될 것이다.T또는x그것은 생산할 수 없다.Truthy<T>(그렇지 않으면)T==의 유형x이 경우 이 전체 토론은 무가치한 것이다.이것을 새로운 유형이라고 합시다.Falsy<T> XOR Maybe<U>.

의 규칙은 무엇인가?Falsy<T> XOR Maybe<U>인가요?

• 분명히 의 속성을 사용할 수 없다.T 만약 그 이라면.T그것은 가짜고 사용하기에 안전하지 않다.
• 당신은 그것을 a로 사용할 수 있어야 한다.Maybe<U>, 그 이후Falsy<T>그리고Falsy<U>행동거지가 있다
• 의 속성을 사용할 수 없어야 함U값이 여전히 거짓일 수 있기 때문이다.
• 만약 당신이 그것을 사용한다면if테스트, 그리고 나서 그것은Truthy<U> 에.if성명서

바꾸어 말하면, 환언하면Falsy<T> XOR Maybe<U> 이다 Maybe<U>그것은 모든 같은 규칙을 따른다.여기에 이 이상한 것을 덧붙여서 타이프 시스템을 전혀 복잡하게 만들 필요는 없다.XOR필요한 모든 사양에 맞는 유형이 이미 존재하기 때문에 입력하십시오.

이것은 마치 누군가에게 상자를 주면서 "이것은 쓰레기 빈 상자, 또는 재활용품을 가득 담은 상자"라고 말하는 것과 같다.상자 안의 내용물을 재활용통에 안전하게 비울 수 있다.

언어사양이 유지되지 않고, 이 경우에는 틀렸다.의 결의 .&&연산자는 오른쪽 측면의 유형과 왼쪽 측면의 거짓 값의 결합이다.

TypeScript 2.0 릴리스 정보:

// Compiled with --strictNullChecks
declare function f(x: number): string;
let x: number | null | undefined;
// ..
let b = x && f(x); // Type of b is string | 0 | null | undefined

참조URL: https://stackoverflow.com/questions/12693787/why-does-the-operator-produce-the-type-of-the-second-operand