Allow `interface extends object` syntax

🔍 Search Terms

interface extends object

✅ Viability Checklist

• This wouldn't be a breaking change in existing TypeScript/JavaScript code
• This wouldn't change the runtime behavior of existing JavaScript code
• This could be implemented without emitting different JS based on the types of the expressions
• This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
• This isn't a request to add a new utility type: https://github.com/microsoft/TypeScript/wiki/No-New-Utility-Types
• This feature would agree with the rest of our Design Goals: https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals

⭐ Suggestion

I propose to allow the following syntax:

interface MyInterface extends object {}

This would have identical semantics to the following (currently legal) syntax:

type _object = object
interface MyInterface extends _object {}

Details:

1. No primitive may be assigned to such an interface or an intersection containing such an interface
2. This requirement is inherited by any extending interfaces

I'm requesting this feature mainly because it was the only pain-point mentioned in this related issue. To quote:

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;

Regardless of the outcome of that other issue however, it would be nice to be able to extends object without going through that kind of hassle.

📃 Motivating Example

A small usability improvement to allow interfaces to more easily declare that primitives cannot be assigned to them.

💻 Use Cases

1. What do you want to use this for? To avoid non-idiomatic verbosity
2. What shortcomings exist with current approaches? Non-idiomatic verbosity
3. What workarounds are you using in the meantime? Non-idiomatic verbosity

Start by reviewing the proposed interface extends object syntax and the linked related issue #60582. No implementation files or tests are named, so trace the relevant interface heritage and assignability handling before defining tests for the stated primitive-assignment semantics.