Rethinking relationships between `{}` type, `object`, and primitives

[kirkwaiblinger]

🔎 Search Terms

empty object type, {}, type safety violation, unsound

🕗 Version & Regression Information

• This is the behavior in every version I tried, and I reviewed the FAQ for entries about object types and structural typing

⏯ Playground Link

https://www.typescriptlang.org/play/?ts=5.8.0-dev.20241124#code/GYVwdgxgLglg9mABFAhgawKYGcDyAjAKw2gAoAPALkTkOKgEpEBvAKEXcQHpPEAVACxhZEAJxgBzflAA2AT0RDEKPgGVEGESLgiAdGw4xgicogC85xAAZGrDncQQEWONIw6NWkSQDkAxXhEUSH5ELH44EGkAE0Q8DERwEQwUCH4UPFdvegBufXYAXxZClkcwLChqKiZ8sytclm5EACEQCqhBYSEwbygAGiUwGLCI6Ni3FlRMXFpSOBygA

💻 Code

function takesObject(x: object) {
 // This rightly is a TS error.
 if (x === 0) {
 console.error('This branch should be unreachable');
 }
}

const o: {} = 0;

// But this isn't, and should be.
takesObject(o);

🙁 Actual behavior

No error on takesObject(o). {} can be assigned to type object, despite {} meaning "all nonnullish values", whereas object means only JS object types.

🙂 Expected behavior

Error on takesObject(o). {} is a wider type than object.

Additional information about the issue

This stems from a typescript-eslint investigation into making no-unnecessary-condition be more correct around possibly-falsy "object types", such as {}, or even {toFixed(): string} (to which number may be assigned). See typescript-eslint/typescript-eslint#10378. This also relates to previous (controversial) conversations about whether to flag the {} type with the linter, see, e.g. typescript-eslint/typescript-eslint#8700.

I'm wondering if this was simply an oversight in #49119, which aimed to fix soundness holes with {}?

[jcalz]

duplicate #56205

[JoshuaKGoldberg]

Even if it's a duplicate, given #56205 (comment):

Allowing {} to be used as object is an intentional compatibility hole since object didn't always exist, so people used {} as the next-best thing.

I read this new issue as a request to not do that. As in, now that TypeScript has had better handling around {} and object for a while (refs: #49119, #57735 (comment)). Over in typescript-eslint we've overhauled our lint rules around the empty object types to respect the new behaviors and best practices (typescript-eslint/typescript-eslint#8700 -> https://typescript-eslint.io/rules/no-empty-object-type). This hole is a sticking point. +1 from me on filling in the hole.

[jcalz]

Is it just {}? So would {a: string} still be assignable to object or not? What about {length: number}?

[JoshuaKGoldberg]

Personally, I'm of a "strict" interpretation: that any {... } type coincidentally assignable to a non-object primitive should not be assignable to object. Only with object & should they be. Quick examples:

• {}: as discussed
• {length: number }: because of string
• {toPrecision(): string } and {toPrecision(precision?: number): string }: because of number

This is probably tricky from an implementation perspective. But it's right.

[fatcerberus]

@JoshuaKGoldberg So you're suggesting that this shouldn't be allowed:

let obj: { length: number } = { length: 10 };
const o: object = obj;

Simply because obj could also hypothetically be a string?

[kirkwaiblinger]

So you're suggesting that this shouldn't be allowed:

let obj:{length: number } ={length: 10 };
const o: object = obj;
Simply because obj could also hypothetically be a string?

If we're unpacking this in detail, negative - your example should be allowed 🙂 But the reason why is control flow narrowing, which TS already does in other cases as well.

This should be disallowed, though.

let obj: { length: number } = { length: 10 };
// ... lots of code
if (Math.random() > 0.5) {
 obj = "not an object!"
}
// ... lots of code
const o: object = obj;

This should also be disallowed.

declare const objOrString: { length: number };
const o: object = objOrString;

---

Note that similar DevX tricks are applied around nullishness, see, for example,

const constNullishNumber: null | number = 42;
const num1: number = constNullishNumber; // allowed!

let neverReassigned: null | number = 42;
const num2: number = neverReassigned; // allowed!

// vs

let reassigned: null | number = 42;
if (Math.random() > 0.5) { 
 reassigned = null;
}
const num3: number = reassigned; // not allowed!

[fatcerberus]

@kirkwaiblinger

If we're unpacking this in detail, negative - your example should be allowed 🙂

Yes, that was the point of the comment - it was a counterexample for @JoshuaKGoldberg's original argument.

[kirkwaiblinger]

@fatcerberus

Yes, that was the point of the comment - it was a counterexample for @JoshuaKGoldberg's original argument.

...and I'm saying I don't see how it's a counterexample at all? It's just an edge case that would need to be handled by the same sleight-of-hand that TS already includes in similar situations.

Regardless, this is perhaps an implementation detail consideration that's not worth spending too many more words going back and forth on before we even find out if this issue will be summarily closed as a duplicate or not 😆. So I'll leave it there for now to avoid noise in the issue conversation. But definitely an important detail to handle if this does get to the point of implementation! 🙂

[RyanCavanaugh]

We would need some proposal that creates the desired behavior without unacceptable negative side effects (we've taken several bites at this apple before and not come up with much that was particularly appetizing). No one is going to turn on this behavior if it means every time they write

interface Person {
 name: string
}

they actually need to write

interface _PersonFields {
 name: string;
}
type Person = object & _PersonFields;

to get something that's properly assignable to object, since in practice that's the only kind of thing that can inhabit Person anyway.

IMO the right fix here isn't making {} un-assignable to object, it's making objectness an intrinsic property of writing {} syntax in the first place, and then figuring out how to work backwards to a way to talk about types where you accept a {length: number } and don't care if it's an Array or a string. Maybe that's just giving up and saying that you have to write {length: number } | string.

Or maybe that's some kind of syntax around how the global String type is declared, e.g.

interface String notextends object {
 length: number;
}

which would create a type that didn't have intrinsic object-ness. Point being, you should not (generally) have to do extra work to opt in to the existing behavior as relates to being able to assume that types are object unless known to be primitive.

[kirkwaiblinger]

@RyanCavanaugh

I am enthusiastically on board with considering how to make it so that {... } types are objects! I only framed the issue in the way I did on the assumption that that would be a nonstarter. But I agree with every word in #60582 (comment) 🙂

I guess, before thinking too deeply to reinvent the wheel, I would be pretty interested to know how far down the rabbit hole those of you on the TS team have gone when pondering this previously, and what undesirable edge cases might have arisen. Do you have references on this that I might look into?

My first thought is that the overarching model here would be that the runtime JS type, i.e. the result of x === null ? 'null' : typeof x, would additionally be tracked in TS's type system. If for niche usages a Structural<T> intrinsic type needs to be provided, it could return the exact same type but with any associated runtime type (and therefore, for example, Structural<BoxedNumber> would be more or less identical to Structural<number>, apart from possibly readonlyness).

Since I can't help it, I've started to think through some details and consequences of this, but, as mentioned, probably it's best to catch up to where you are first, before dropping walls of text here 😀

Excited to be having this conversation!