Allow private class field notation in parameter properties

[TimvdLippe]

Suggestion

🔍 Search Terms

"Private identifiers cannot be used as parameters"

✅ Viability Checklist

My suggestion meets these guidelines:

• 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 feature would agree with the rest of TypeScript's Design Goals.

⭐ Suggestion

Allow private fields in parameter properties notation

📃 Motivating Example

class ReadOnly {
  constructor(#firstProp: string, #secondProp: number, #thirdProp: number) {}

  someMethod() {
    this.#firstProp = 42;
  }
}

💻 Use Cases

Parameter property syntax saves quite a bit of boilerplate for class initialization, especially for large classes (which tends to be the case in the DevTools codebase). We are currently considering adopting private class fields in our codebase (for runtime bundle size optimizations) and this limitation was pointed out.

During my search, I did find https://github.com/microsoft/TypeScript/blob/663b19fe4a7c4d4ddaa61aedadd28da06acd27b6/tests/baselines/reference/privateNamesNotAllowedAsParameters.errors.txt which encodes the current behavior. The test appears to be coming from #30829, but I wasn't able to find a reference to the design decision for this functionality (the "load 214 more comments" throws 502 server errors on GitHub).

I was able to find 1 reference to the functionality here: #37677 (comment) However, I wasn't able to find a response to that question, so I figured filing a separate GitHub issue is better to facilitate the discussion.

[MartinJohns]

Duplicate of #43678. Used search terms: private parameter.

[TimvdLippe]

Ah yes thanks! Not sure how I missed searching for that issue.