ts80007 is incorrect at times?

[ORESoftware]

🔍 Search Terms

async/await conditional is-promise promise

✅ Viability Checklist

• 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, new syntax sugar for JS, etc.)
• This isn't a request to add a new utility type: https://github.com/microsoft/TypeScript/wiki/No-New-Utility-Types
• This feature would agree with the rest of our Design Goals: https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals

⭐ Suggestion

For reference, isPromise(x) looks like:

(client as any).ensure = () => {
  if (client.isOpen) {
    return;
  }
  return client.connect();
}

const isPromise = (x: any) => {
  return x && typeof x.then === 'function' && typeof x.catch === 'function';
}

here is what I saw:

this is pretty handy code, IMO, more performant etc, big win, but at the same time we all like to avoid if/else where possible, in this case, I think TS shouldn't complain?

📃 Motivating Example

see above

💻 Use Cases

1. What do you want to use this for? async/await optimizations
2. What shortcomings exist with current approaches?
3. What workarounds are you using in the meantime?

[fatcerberus]

This one isn't a compile error though, is it? I thought it was just a lightbulb in the IDE and you're free to ignore it.

[andrewbranch]

Just write the return type of isPromise as x is Promise<any> if you want to make the types accurate enough for this suggestion diagnostic to follow

[typescript-bot]

This issue has been marked as "Working as Intended" and has seen no recent activity. It has been automatically closed for house-keeping purposes.