Compiler cannot handle promise.then(null | undefined) about typescript HOT 7 OPEN

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.

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.