Automatically Assign Constructor Parameters as Class Properties in TypeScript

[Phaneendra-Pallapothu]

🔍 Search Terms

Currently, in TypeScript, when we define a constructor (concise way), parameters do not automatically become class properties unless explicitly marked with public, private, or protected.

✅ 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 that constructor parameters should default to public if no access modifier is specified.

This means:
-> Explicit access modifiers (private, protected) should still behave as expected.
->If no modifier is given, TypeScript should automatically treat the parameter as public.

📃 Motivating Example

Current Behaviour:
class Student {
constructor(public name: string, public age?: number, public address?: string) {}
}

Suggested Behaviour:
class Student {
constructor(name: string, age?: number, address?: string) {}
}

💻 Use Cases

Why This Change?
✅ Reduces Redundancy – No need to explicitly write public when it's the default behavior.
✅ Improves Developer Experience – Constructor parameters are typically meant to be class properties, so it makes sense for TypeScript to assume public.
✅ Keeps Code Clean & Readable – Avoids unnecessary boilerplate.

[MartinJohns]

This would be a massive huge breaking change, without an apparent opt-out.

It would also violate this point from the Viability Checklist:

This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)

(The existing behavior violates this already, but predates the decision to not add any more runtime functionality.)

Constructor parameters are typically meant to be class properties,

I disagree. There are many cases where this is not the case.