Accessing protected computed property does not produce a compiler error

[parzhitsky]

🔎 Search Terms

protected computed no error bug

🕗 Version & Regression Information

This is the behavior in every version I tried (v3.3.3333, v4.0.5, v5.7.3), and I reviewed the FAQ for entries about Common "Bugs" That Aren't Bugs

⏯ Playground Link

https://tsplay.dev/wjdn7m

💻 Code

declare class Foo {
  protected readonly baz = 42
}

declare class Bar {
  readonly foo: Foo
}

declare const bar: Bar

// @ts-expect-error
console.log(bar.foo["baz"].toFixed(2))

🙁 Actual behavior

• (without // @ts-expect-error): No errors
• (with // @ts-expect-error): Compiler error Unused '@ts-expect-error' directive

🙂 Expected behavior

• (without // @ts-expect-error): Compiler error Property […] is protected and only accessible within class 'Foo' and its subclasses
• (with // @ts-expect-error): No errors

Additional information about the issue

No response

[jcalz]

This is working as intended, duplicate #19335

[parzhitsky]

(I'd respond in the original issue, but it is limited to collaborators only)

I think, there needs to be a distinction between intended usage of bracket notation where dot notation is available, and unavoidable usage of bracket notation where dot notation is not available. I.e., my original use case is using a symbol as property key, – I can't not use bracket notation:

const key = Symbol('key')

declare class Foo {
  protected readonly [key]: number
}

declare class Bar {
  readonly foo: Foo
}

declare const bar: Bar

console.log(bar.foo[key].toFixed(2)) // no errors 🙁

Try it.

AFAICT, TypeScript parser already has a mechanism to differentiate literals (such as foo["bar"]) from expressions (such as foo["b" + "a" + "r"]).

[parzhitsky]

Should I open a feature request?

[MartinJohns]

How could you even distinguish the two cases?

[jcalz]

You could possibly file a feature request, but similar things like #50485 have been declined. Not sure if someone has brought up symbol keys before, but I imagine you'll get the same response.

[RyanCavanaugh]

Enough people dislike #19335 that there's probably room for something like strictClassPropertyAccess that would disallow the private-evading syntax carve-out. I'm sure a lot of codebases don't actually use it intentionally.

[parzhitsky]

@MartinJohns I believe this mechanism would be similar to (if not the same as) one that works here:

("value") as const // no error
("va" + "lu" + "e") as const // error