TypeScript strangely expanding out boolean into true/false in type alias.

[CyrusNajmabadi]

Using TS 3.3.1. strictNullChecks, noImplicitAny.
Code in question:

interface pojo { b: boolean }

type primitive = Function | string | number | boolean | undefined | null;
type SimpleInput<T> = T | Promise<T>;

type Input<T> =
    T extends primitive ? SimpleInput<T> :
    T extends object ? SimpleInput<InputObject<T>> :
    never;

type InputObject<T> = {
    [P in keyof T]: Input<T[P]>;
}

var ip2: Input<pojo> = { b: Promise.resolve(true) };

Error is reported as:

Type '{ b: Promise<boolean>; }' is not assignable to type 'SimpleInput<InputObject<pojo>>'.
  Type '{ b: Promise<boolean>; }' is not assignable to type 'InputObject<pojo>'.
    Types of property 'b' are incompatible.
      Type 'Promise<boolean>' is not assignable to type 'boolean | Promise<false> | Promise<true>'.
        Type 'Promise<boolean>' is not assignable to type 'Promise<false>'.
          Type 'boolean' is not assignable to type 'false'.

It's unclear to me why/how this is happening. The expansion of Input<pojo.b> seems to have become boolean | Promise<true> | Promise<false> instead of boolean | Promise<boolean>.

is this expected? a bug? If intentional, is there some sort of workaround?

[CyrusNajmabadi]

Note: even if ths is intentional, and TS expands out boolean to true | false in something like a mapped type, then it seems super strange to me that Promise<boolean> is not compatible with ... | Promise<true> | Promise<false>. Promise<boolean> could only be Promise<true> | Promise<false> so these types should be complimentary AFAICT.

[CyrusNajmabadi]

Tagging @RyanCavanaugh @DanielRosenwasser :)

[AnyhowStep]

The distribution is coming from T extends primitive.

Your T is boolean, which is really true|false.

Conditional types distribute, which gives you,

true|false|Promise<true>|Promise<false>

But true|false is simplified to boolean

And you get boolean|Promise<true>|Promise<false>

[CyrusNajmabadi]

@AnyhowStep I addressed that here: #30029 (comment)

My general complaint is that even with that expansion, it seems overly onerous that TS then doesn't consider the type compatible. Despite it appearing that there would be no reasonable way to observe a difference.

[AnyhowStep]

Promise<boolean> is not assignable to Promise<true> | Promise<false>.

declare function isTruePromise (p : Promise<any>) : p is Promise<true>;

const booleanPromise : Promise<boolean> = Promise.resolve(Math.random() > 0.5);
//Assume this will not error
const p : Promise<true> | Promise<false> = booleanPromise;

if (isTruePromise(p)) {
    p.then(console.log); //Expected to ALWAYS print `true`
} else {
    p.then(console.log); //Expected to ALWAYS print `false`
}

However, we can see that neither expectation can be satisfied.

[CyrusNajmabadi]

I honestly don't get your example. Why would neither expectation be satisfied? For a promise, once its value is resolved, it can't change. So, a Promise<boolean> is literally only able, at the end of the day, to finally be a Promise<true> or a Promise<false>. i.e. Promise<true> | Promise<false>.

IN the case of your code if the wrong thing runs, it's because your isTruePromise actually lied and didn't properly assess what type of Promise this was. But that's not TS's fault. it would be hte same as any sort of other incorrect truthy check which TS just trusted because it was an : foo is bar checking function.

[AnyhowStep]

Fair enough. I forgot that the resolved value doesn't change.

But the type system doesn't know that. It cannot assume that a value does not change between invocations. You can argue that it should be assignable for Promise<boolean>, but it doesn't work in the general case.

function b() {
    return Math.random() > 0.5;
}
//Pretend this works
/*
Type '() => boolean' is not assignable to type '(() => true) | (() => false)'.
  Type '() => boolean' is not assignable to type '() => true'.
    Type 'boolean' is not assignable to type 'true'.
*/
const f: (() => true) | (() => false) = b;

declare function isTrueFunc(f: any): f is (() => true);
if (isTrueFunc(f)) {
    for (let i = 0; i < 100; ++i) {
        //Expected to always return true
        console.log(f())
    }
} else {
    for (let i = 0; i < 100; ++i) {
        //Expected to always return false
        //But we know that it will switch between
        //true and false
        console.log(f())
    }
}

[CyrusNajmabadi]

but it doesn't work in the general case.

Again, that's because your isTrueFunc is lying :)

Yes, if you make a lying type-check function, all bets are off. That is the case today. That's why Promise<true> | Promise<false> is equiv to Promise<true | false>. Let's say you have the former, each time you do anything with it, you have to assume it could be either Promise<true> or Promise<false>. That means that any usages of it's values would have to be acceptable given either of those interpretations. Turns out this means you need to be able to handle true or false. which is the same contract that Promise<true|false> give you.

Heck, this is why it's safe to map boolean to true|false in the first place.

[AnyhowStep]

Here's a case where Promise<boolean> is not assignable to Promise<true>|Promise<false>. In function return types.

function b() {
    return Promise.resolve(Math.random() > 0.5);
}
//Pretend this works
const f: (() => Promise<true>) | (() => Promise<false>) = b;

declare function isTrueFunc(f: any): f is (() => Promise<true>);
if (isTrueFunc(f)) {
    for (let i = 0; i < 100; ++i) {
        //Expected to always print true
        f().then(console.log);
    }
} else {
    for (let i = 0; i < 100; ++i) {
        //Expected to always print true
        //But it will switch between true and false
        f().then(console.log);
    }
}

[AnyhowStep]

You're forgetting the false branch.

In the false branch, f is now () => false because it is not () => true.

But it is not () => false because it can return true.

[CyrusNajmabadi]

Previously discussed at: #22596

[CyrusNajmabadi]

In the false branch, f is now () => false because it is not () => true.

Right. Because your typecheck was incorrect.

[AnyhowStep]

The type guard function will return false.

There is no way function b is () => true. We agree on that.
The type guard function is not malfunctioning.

You want it to be possible for () => boolean to be assignable to (() => true)|(() => false) but I'm showing you that this leads to undesirable results.

Because this (() => true)|(() => false) = b is not (() => true), the type guard will return false.
And because it returns false, the type of the function is now narrowed to (() => false).

But this is not right. It is still () => boolean.

This only happened because we assigned () => boolean to (() => true)|(() => false). Not because the type guard is wrong.

---

Assigning () => boolean to (() => true)|(() => false) is the only incorrect typecheck here.

[CyrusNajmabadi]

The type guard function will return false.

I'm saying: that is a lie as well. Your function cannot make a claim one way or the other. it would be the same as if you had a system which could encode numbers, and you had a typecheck that said this function will return a value > 10, but you then ran that on a random number generating function. It would not be legal to say either true or false. You cannot make a claim in any direction about this.

[AnyhowStep]

How is it a lie?

() => Math.random() > 0.5 is not assignable to () => true. The return value could be true or false depending on the PRNG.

So, if the type guard is working, it will return false