Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Type narrowing for awaited values #30551

Open
5 tasks done
samdenty opened this issue Mar 22, 2019 · 4 comments
Open
5 tasks done

Type narrowing for awaited values #30551

samdenty opened this issue Mar 22, 2019 · 4 comments
Labels
Awaiting More Feedback This means we'd like to hear from more people who would be helped by this feature Suggestion An idea for TypeScript

Comments

@samdenty
Copy link

samdenty commented Mar 22, 2019

Search Terms

promise, type narrowing, await

Suggestion

The type narrowing that occurs inside if statements, should work with awaited values

Though generally speaking a type is used for values that are already

Examples

type A = {
  kind: 'a'
  a: string
}

type B = {
  kind: 'b'
  b: string
}

let data: A | B

async function valueTest() {
  if ((await data.kind) === 'a') {
    // 'data' hasn't been narrowed to type 'A'
    data.a // Error
  }

  // Works fine without await
  if (data.kind === 'a') {
    data.a // Okay
  }
}

Checklist

My suggestion meets these guidelines:

  • This wouldn't be a breaking change in existing TypeScript/JavaScript code
  • This wouldn't change the runtime behavior of existing JavaScript code
  • This could be implemented without emitting different JS based on the types of the expressions
  • This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
  • This feature would agree with the rest of TypeScript's Design Goals.
@MartinJohns
Copy link
Contributor

This is due to #9998.

@DanielRosenwasser
Copy link
Member

DanielRosenwasser commented Mar 25, 2019

I think it's more that there's a limited set of syntactic constructs we can analyze because it would be inefficient otherwise. I guess the thing I want to know is whether there's a reason to write code like that.

@RyanCavanaugh RyanCavanaugh added Awaiting More Feedback This means we'd like to hear from more people who would be helped by this feature Suggestion An idea for TypeScript labels Mar 26, 2019
@jeremymeng
Copy link
Member

I guess this is the same issue that for-await-of doesn't narrow types?

/// <reference lib="esnext.asynciterable"/>

interface MyIterator<T> {
  next(): Promise<
    | {
        done: false;
        value: T;
      }
    | {
        done: true;
        value: undefined;
      }
  >;
  [Symbol.asyncIterator](): MyIterator<T>;
}
interface Item { name: string }

async function m(iter: MyIterator<Item>) {
  for await (const it of iter) {
    console.log(it.name);           // Error here complaining about 'it': Object is possibly 'undefined'.ts(2532)

  }
}

@jeremymeng
Copy link
Member

hmm, actually it is not related to await. iterator has the same error

interface MyIterator<T> {
    next():
      | {
          done: false;
          value: T;
        }
      | {
          done: true;
          value: undefined;
        }
    ;
    [Symbol.iterator](): MyIterator<T>;
}

interface Item { name: string }

function m(iter: MyIterator<Item>) {
    for (const it of iter) {
        console.log(it.name);           // Error here complaining about 'it': Object is possibly 'undefined'.ts(2532)

    }
}

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Awaiting More Feedback This means we'd like to hear from more people who would be helped by this feature Suggestion An idea for TypeScript
Projects
None yet
Development

No branches or pull requests

5 participants