Closed
Description
Search Terms
Promise, conditions, if, truthiness, coercsion, known-true
Related
Suggestion
Non-nullable promises should not be implicitly converted to truthy inside of conditions.
Use Cases
This helps prevent common bugs where promises aren't await
-ed (see below).
Examples
async isAllowedToDoTheSuperSecretThing(user: User) {
/* ... */
}
async doTheSuperSecretThing(ctx: RequestContext) {
if (isAllowedToDoTheSuperSecretThing(ctx.user)) {
/* do the super secret thing */
}
}
should result in an error since isAllowedToDoTheSuperSecretThing
returns a non-nullable promise and is never falsey.
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.
This definitely falls into the camp of goal one:
Statically identify constructs that are likely to be errors.
This would be breaking but so is #33178.