override keyword not honored for methods of Object on classes with no extends, Object super members missing

[trusktr]

Bug Report

All classes without an extends clause implicitly extend from Object. However the override keyword does not work when overriding members of Object, and I believe it should for consistency, semantics, and display of developer intent.

Furthermore, TypeScript chooses to hide super members of Object, and the following valid JavaScript has an unexpected type error:

class Foo {
  toString() {
      return super.toString() + ' ' + 123 // Error: 'super' can only be referenced in a derived class. (2335)
  }
}

new Foo().toString() // This works just fine in JavaScript.

The class is implicitly derived (from Object), and super.toString exists.

🔎 Search Terms

🕗 Version & Regression Information

I don't think it ever worked?

⏯ Playground Link

Playground link with relevant code

Playground link with relevant code

🙁 Actual behavior

No type information is present for inherited Object members inside a class without extends.

Possibly related: even on any plain object like a POJO, intellisense in VS Code does not show helpful autocompletion for Object members.

🙂 Expected behavior

It should show the full picture, because it is valid JavaScript.

[RyanCavanaugh]

This would be a breaking change for people who have a custom toString and turned on noImplicitOverride.

It seems like if you're explicit enough to be specifying that toString is an override, then writing class Foo extends Object should also be a thing you'd want to write.

[DanielRosenwasser]

This would be a breaking change for people who have a custom toString and turned on noImplicitOverride.

This doesn't necessarily require issuing an error on noImplicitOverride, though the workaround would be relatively simple for codebases who are opting themselves into noImplicitOverride. It might be a breaking change for .d.ts that don't at least allow specifying override on Object members.

Really what I'm getting is that we should at least allow specifying override if a member is declared on Object. If we wanted to have a two phase process of

1. first allowing override and then
2. erroring on its absence in noImplicitOverride

that might not be a bad idea.

In the meantime though, an explicit extends Object does seem like a reasonable workaround.

[RyanCavanaugh]

noImplicitOverride today has the goodness that it works just like jumping in checkers: If you can write override, you must

Turning that from a boolean (must write, cannot write) to a tristate (must write, may write, cannot write) is a big can of worms.

[DanielRosenwasser]

I forgot about the fact that override gets stripped away in .d.ts files, so I think you're right, it might be best to keep the two in sync.

[myknbani]

@RyanCavanaugh

This would be a breaking change for people who have a custom toString and turned on noImplicitOverride.

It seems like if you're explicit enough to be specifying that toString is an override, then writing class Foo extends Object should also be a thing you'd want to write.

how about another compiler option like "implicitExtendObject" 🥴 😁 ?

[trusktr]

It seems like if you're explicit enough to be specifying that toString is an override, then writing class Foo extends Object should also be a thing you'd want to write.

Every JS programmer should know that class Foo {} extends from Object by default (because it effectively does!). But that's a good workaround for base class authors only too.

Some people are importing classes from libraries, for example, and forking a library just to add extends Object to a library's base class is not ideal.

What about an new option noImplicitObjectOverrides that defaults to false, then deprecate implicit Object overrides, and eventually switch the default to true (at least for strict mode)?