Late bindable index signatures on classes vs `override` and `noImplicitOverride `

[Andarist]

🔎 Search Terms

override ambient type declaration class dts noImplicitOverride late bindable index signatures

🕗 Version & Regression Information

• This changed in commit or PR: Support interpreting non-literal computed properties in classes as implicit index signatures #59860

⏯ Playground Link

https://www.typescriptlang.org/play/?noImplicitOverride=true&ts=5.8.0-dev.20241128#code/PTAEAEDsHsEkFsAOAbAlgY1QFwPIDcBTAJyNQBMCAuULIgVwIChH1pIBnLUdgT3mt7wARtGSgAvKADKfEcgAUASgDczdMgCG7dqABCWggEZQAb0ahQAbUEBdJaYC+jJy03bQAEWKpCZYwQAPLAJIMh19diNTc1BoQhJyAitbexMnF3UtcIMAJmiLaz47RUdnNTcdL1JfPMDg0OzIvLMClJK0stcsvQMAZlKu9yqfAjJ+upCwnsj+ltj40gpkotT0oA

💻 Code

// @noImplicitOverride: true

const sym: symbol = Symbol();

class Base1 {
  [sym]() {}
}

class Derived1 extends Base1 {
  override [sym]() {}
}

class Base2 {
  [sym]() {}
}

class Derived2 extends Base2 {
  [sym]() {}
}

class Base3 {}

class Derived3 extends Base3 {
  override [sym]() {}
}

🙁 Actual behavior

No errors are raised

🙂 Expected behavior

I'd expect either:

• errors on override with dynamic names
• errors raised on override members without override under noImplicitOverride

Additional information about the issue

I implemented the first suggestion here f334978 but since I don't know if this is the desired behavior I didn't open a PR with this change yet, cc @weswigham

[weswigham]

Yeah, @Andarist I'm just gonna go ahead and say we can issue errors on override on dynamic-named class members. It's not a regression, since we haven't issued errors on them before (we just also didn't check them before), but we probably should, since it likely indicates that you don't realize you're not actually overriding a specific member. We also just straight up don't allow override on actually declared index signatures, so allowing it on implicit ones would be wonky. Feel free to open a PR with your commit.