`let a = {}` infers `{}` instead of `object`, which seems too wide for the initializer

[5cover]

🔎 Search Terms

empty object inferred as {} instead of object

🕗 Version & Regression Information

This is the behavior in every version I tried, and I reviewed the FAQ for entries about { } Does Not Refer to Objects With No Properties.

⏯ Playground Link

https://www.typescriptlang.org/play/?#code/DYUwLgBAhhC8EG8C+BuAsAKBvArCiA9AdMMAPYDuIAJkA

💻 Code

let a = {};
a = 5; // allowed

🙁 Actual behavior

The empty object literal infers as {}.

Since {} is assignable from all non-nullish values, this assignment changes the fundamental runtime category of the variable.

This is surprising given the initializer. From let a = {}, we know that:

• the value is an object
• it has no known properties

However, the inferred type {} does not preserve the "object-ness" of the initializer and instead allows primitives.

🙂 Expected behavior

object seems like a more faithful inferred type than {}.

If a were inferred as object, then:

let a = {};
a = 5; // error

which appears more consistent with the runtime category of the initializer.

This also matches how other initializers behave:

let b = 5;
b = {}; // error

A numeric initializer does not widen to a type that also accepts objects. By contrast, {} currently widens to a type that also accepts primitives.

Additional information about the issue

This affects generic utilities and conditional types that reason about broad categories of values.

For example, because {} includes non-nullish primitives, utilities that inspect or classify types can get surprising results when fed the inferred type of {}.

More broadly, it seems odd that an object literal can infer to a type that later permits assignment of primitive values, unless that widening was explicitly requested via annotation.

Cosnidering {} has long-standing semantics in TypeScript and that changing inference here would likely be breaking, I am not proposing that this must change unconditionally.

However, it seems reasonable to ask whether:

• the current inference is truly the intended design, or just a consequence of existing {} semantics
• object would be a better inference target for the specific case of the empty object literal initializer
• this could make sense behind a strictness flag, e.g. something like strictEmptyObjectInference

If someone wants the broader behavior, they can always write it explicitly:

let a: {} = {};
a = 5; // allowed

So inferring object from {} would not remove access to the current behavior; it would only stop opting into it implicitly.

Is inferring {} from let a = {} considered the intended design?

If so, what is the rationale for preferring {} over object?

And if not, would an opt-in stricter mode be worth considering?

[MartinJohns]

Essentially a duplicate of #60582.

It's a fundamental issue in TypeScripts type system that is not limited to the empty object. For example this also causes issues:

let a: { length: number } = { length: 123 };
a = "abc"

// a looks like an object, but may be a string.

[RyanCavanaugh]

This is surprising given the initializer. From let a = {}, we know that: the value is an object, it has no known properties

You can make this argument in any way, though. From

let a = 10

we know that: the value is 10. Therefore it should be an error to write

a = 11;

There isn't a straightforward process of choosing the exact single right answer of how far to widen a mutable declaration. It is necessarily heuristical.

[5cover]

Essentially a duplicate of #60582.
It's a fundamental issue in TypeScripts type system that is not limited to the empty object.

My question is specifically about inference. In:

let a = {};
a = 5; // allowed

This happens because {} is inferred, which is very wide. But from the initializer we only know "object with no known properties", so object seems like a more faithful inferred type.

This is surprising given the initializer. From let a = {}, we know that: the value is an object, it has no known properties

You can make this argument in any way, though. From

let a = 10

we know that: the value is 10. Therefore it should be an error to write

a = 11;

There isn't a straightforward process of choosing the exact single right answer of how far to widen a mutable declaration. It is necessarily heuristical.

Right, I'm not arguing for "no widening". let x = 10 widening to number makes sense because reassignment still stays within the same typeof category.

My concern is narrower: for object literals, current widening can cross runtime categories without an explicit annotation.

If a were inferred as object, reassignment would still be possible, just not to a primitive. So the question is where the widening heuristic draws the line, and whether it should avoid implicitly widening across typeof categories for {} literals.

[RyanCavanaugh]

It would, at minimum, imply a variance discontinuity that would be an additional "why is TypeScript so inconsistent?" thing to deal with.

But from the initializer we only know "object with no known properties", so object seems like a more faithful inferred type.

This is begging the question.