Type of `([].length > 1 && {})` can be false but Typescript cannot detect it

[omidh14]

Bug Report

🔎 Search Terms

object type condition parenthesis

🕗 Version & Regression Information

• This is the behavior in every version I tried, and I reviewed the FAQ.

⏯ Playground Link

Playground link with relevant code

💻 Code

// This throws an error as expected because "Spread types may only be created from object types"
const invalid = { ...(false) }

// This does not throw even though the value in parenthesis would also be resolved to `false` which
// is a side effect of wrong type detection. This assignment is allowed because Typescript cannot detect
// that there is a possibility that the value inside the parenthesis would be `false`.  
const valid = { ...([].length > 1 && {}) }

const wrongTypeDetection = ([].length > 1 && {}) // type of wrongTypeDetection is {} instead of false | {} 

🙁 Actual behavior

Type of const wrongTypeDetection = ([].length > 1 && {}) is {}

🙂 Expected behavior

Type of const wrongTypeDetection = ([].length > 1 && {}) should be false | {}

[fatcerberus]

false is assignable to {}.

[omidh14]

@fatcerberus Who told you that?
then why const invalid = { ...(false) } shows error?

or why this does not work?

const obj: { } = {}
obj = false;

[fatcerberus]

You can’t reassign a const. Change that to let and you’ll see the assignment succeeds.

[fatcerberus]

Anyway, this is effectively a design limitation. Subtype reduction reduces an expression typed as false | {} to just {} (because the former is assignable to the latter) and then the error can’t be detected based on the types.

[RyanCavanaugh]

false is an inhabitant of { }. There's nothing incorrect about this behavior.

[fatcerberus]

@RyanCavanaugh Well, to be fair, normally this happens...

const x = { ...false };  // error: Spread types may only be created from object types.

It's just that subtype reduction is kicking in here and reducing false | {} to {} which bypasses the error.

[omidh14]

If this behavior is expected then it should not show that Spread types may only be created from object types error either.

[omidh14]

let record: Record<string, unknown> = {};
record = false; // Shows error, definitely false is not an "inhabitant" of a Record type.
const valid = { ...([].length > 1 && record) } // However this still works 
const valid2: Record<string, unknown> = { ...([].length > 1 && record) } // Even this still works 

const x: {[x: string]: unknown} = { ...false }; // Spread types may only be created from object types 

[RyanCavanaugh]

You're suggesting that TypeScript just be worse on purpose. To what end?

[omidh14]

@RyanCavanaugh I simply want Typescript to be consistent.

Just forget my original report which I thought the problem was that Typescript is not differentiating between { } and false | { } but I was wrong because Typescript still not complaining even if the type of value in the parenthesis is false | Record<string, unknown>!

Now suppose we have a record defined like this:

const record: Record<string, unknown> = {};

Can you give me a reason why const x = { ...(false as boolean && record) } is valid but const x = { ...(false as boolean) } is not?

You might argue Typescript is not detecting the fact that there is a chance the value in parenthesis can be false but that's not true because the type of (false as boolean && record) would be false | Record<string, unknown> if you assign it to a variable.

So why Typescript is not complaining even though it's fully aware of the possibility of the value being false?

@fatcerberus I also like to have your comment because { } is out of the picture now.

[RyanCavanaugh]

Let's say your partner sends you to the store with a shopping list. They say "Get me the things on this list if they have them, but don't get anything not on the list". You look at the list and the item is just "totato". What should you do?

You could go to the store and come back with nothing. That seems like a bad move, since surely something was intended here, and the store never stocks totatos. You could say "Did you mean potato, or tomato?" before leaving. That seems like the right move.

Next week, you go to the store, and they send a carrier pigeon with the shopping list to meet you there (the cell network is down). The list again says "totato". You come back with nothing, since you're not supposed to buy anything not on the list. Did you mess up?

One theory of the situation is that you were wrong to reject the initial list. The instructions were explicit: you should have gone to the store, checked for totatos, and came back with nothing. Errors are not your problem, even if they render the instructions 100% nonsensical.

In another theory of the situation, you shouldn't have agreed to go to the store at all the second time, since you plainly reject some shopping lists and were given no proof that the carrier pigeon would carry a valid list. Your partner might bristle at this - carrier pigeons are very effective at delivering shopping lists, and supplying an up-front proof that the list will not contain problematic items is very difficult.

The third theory is that it's okay to reject some shopping lists with upfront errors, while still accepting future lists even though they can't be checked ahead of time, even though this is not consistent. In fact, this is probably the behavior that's most desired -- identifying detectable early errors is valuable, and accepting late-bound data is valuable, and consistency between the two behaviors is a distant third in terms of importance in being a useful grocery-getter.

By claiming to accept any grocery list you might get in the future, but rejecting some lists you can read right away, you've created a "hole" in the logic of your behavior, since any invalid list can be "made valid" by sending it via pigeon, which is illogical - yet still useful. It's a subtyping symmetry violation. These are usually problematic, but not always -- sometimes if you know more about a situation, you can provide better feedback than if you know less about a situation. That's not a problem! Inconsistency in the face of different situations is not inconsistency, it's application of data.

TypeScript has the same view -- that there are operations which are facially problematic in the presence of statically-determinable facts (object-spreading a value like true, for example, which doesn't do anything), but also operations which might end up doing the same thing (object-spreading {}) which should be presumed OK, because they have safe and reasonable no-op behavior.

[omidh14]

@RyanCavanaugh Thank you for the explanation but that's an overly complicated example that raises more questions than answering them.

But before that, can you also explain why is this invalid in Typescript?

const x = { ...'a string which works fine in vanilla JS' } // Spread types may only be created from object types 

[RyanCavanaugh]

Because that code barely makes any sense. Spreading a string into an object gives you back something that is, for all intents and purposes, garbage. It's neither common nor useful.

[omidh14]

Same as { ...[1, 2, 3] } but why that's allowed though?