Comments (8)
I donāt think thatās the issue thatās being demonstrated here. Minimal repro:
const pNumber = Promise.resolve(0);
const pString: Promise<string> = pNumber.then(); // No error
The issue is that without a callback argument to then
, the only inference source for its type parameter is the contextual type (in my type annotation here, in the function return types in the repro from @blackdyedsheep).
from typescript.
I think this can be solved with overloads, but because overload resolution doesnāt happen during inference, I think itās going to be incredibly breaky. #58678 is up to experiment, but I donāt think it will be viable.
interface Promise<T> {
// specific overloads
then<TResult1, TResult2>(
onfulfilled: (value: T) => TResult1 | PromiseLike<TResult1>,
onrejected: (reason: any) => TResult2 | PromiseLike<TResult2>
): Promise<TResult1 | TResult2>;
then<TResult>(onfulfilled: null | undefined, onrejected: (reason: any) => TResult | PromiseLike<TResult>): Promise<T | TResult>;
then<TResult>(onfulfilled: (value: T) => TResult | PromiseLike<TResult>, onrejected?: null | undefined): Promise<TResult>;
then(onfulfilled?: null | undefined, onrejected?: null | undefined): Promise<T>;
// catch all overload
then<TResult1 = T, TResult2 = never>(
onfulfilled?: ((value: T) => TResult1 | PromiseLike<TResult1>) | undefined | null,
onrejected?: ((reason: any) => TResult2 | PromiseLike<TResult2>) | undefined | null
): Promise<TResult1 | TResult2>;
}
This is fairly accurate and works as expected, for the most part. The specific overloads are all mutually exclusive with each other and are designed to avoid introducing a type variable in the return type of then()
that might not be otherwise witnessed when a callback is null
, undefined
, or not supplied. The catch-all overload allows for various combinations of the specific overloads in cases where you might pass a variable of type (() => T) | null | undefined
as it would not match any of the specific overloads despite being perfectly legal.
Unfortunately, it causes #36307 to regress, so it's still not completely reliable.
Ideally, we could solve this during inference by relying on some heuristic related to the fact that TResult1
has a default and no other inferences aside from the return type. Unfortunately, I haven't yet found a reliable heuristic that doesn't break some other expectation somewhere else.
from typescript.
This is the correct behavior - at runtime, .then(null)
creates a new Promise
with the original underlying value propagated out.
var a = Promise.resolve("hello world").then(null).then(x => console.log(x))
// prints 'hello world'
While you might prefer to never allow null | undefined
to be passed into .then()
, it's both allowed by the spec and permits patterns that are arguably useful (such as optionally-present handlers to transform values).
from typescript.
Whoops, I misread. Apologies.
from typescript.
The easy fix I thought of was to add an overload for optional undefined
/null
, but Iām not sure how well that stacks up against the easiest fix, ājust donāt write .then(null)
.ā Is there a real use case for writing code like that?
from typescript.
Yes, there is a real use case, that's how I came across this behaviour.
Quoting @DanielRosenwasser :
optionally-present handlers to transform values
ie this code should infer Promise<0 | string>
but infers Promise<string>
function maybeTransform(fn?: (v: number) => string) {
return Promise.resolve(0).then(fn);
}
and this code should not compile
function maybeTransform(fn?: (v: number) => string): Promise<string> {
return Promise.resolve(0).then(fn);
}
Basically it should behave the same way as
function maybeTransform(fn?: (v: number) => string) {
return fn ? fn(0) : 0;
}
from typescript.
I think this can be solved with overloads, but because overload resolution doesnāt happen during inference, I think itās going to be incredibly breaky. #58678 is up to experiment, but I donāt think it will be viable.
from typescript.
Probably nobody calls Promise.resolve(0).then<string>()
either except when they do. I'd say it's the same basic issue whether the type is inferred contextually from an unexpected place or the type argument is specified manually: generic defaults don't exactly match the use case, which looks like #56315. The use case in question is something like "when the optional thing is omitted by the caller, it is effectively supplied by the implementer". Generic defaults sort of do this, except when they don't.
from typescript.
Related Issues (20)
- Incorrect Error Message: "Cannot assign to 'name' because it is a constant" Instead of "Identifier 'name' is not defined" for Undefined Identifier Assignment HOT 2
- Generic with extends yields to different type than directly specifying it HOT 4
- Instantiation expressions don't reject incompatible signatures in situations with mixed call and construct signatures HOT 1
- Parameters of overridden methods are made implicit any when using JSDoc `@override` HOT 13
- Auto complete and auto import not work (ReactJS, ChakraUI)
- 'TypeScript and JavaScript Language Features' Formatter hangs HOT 3
- Mapped type of a conditional type unexpectedly fails inference
- Returing a generic argument from a function allows returning a wrong type HOT 1
- Module resolution behaves differently when typeRoots is specified
- Ability to type check setters in interface implementations HOT 2
- ā” Performance: Project service spends excess time cleaning client files when called synchronously HOT 2
- ā” Performance: Project service doesn't cache all fs.statSync HOT 18
- jsxRuntime pragma does not work
- ThisType doesn't enforce type-checking `Object.prototype.call` HOT 2
- ā” Performance: Project service doesn't cache all fs.realpath HOT 1
- `null` prop with `satisfies`, `strictNullChecks: false` + `noImplicitAny: true` gives any report HOT 4
- Debugging failure caused by lack of backtickļ¼`ļ¼
- [proposal] Non widened string values should be valid enum values, like widened string values HOT 1
- 'Could not find source file' with Vue plugin when creating new files and using VS Code's file watcher HOT 6
- Contextual parameters inferred from overloads improvements
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
š Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. ššš
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ā¤ļø Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from typescript.