[feature] class properties that are "readonly in public, writable in private" or other permutations

[trusktr]

Search Terms

typescript readonly on the outside writable on the inside

• https://stackoverflow.com/questions/46634876/how-can-i-change-a-readonly-property-in-typescript

Suggestion

Some sort of syntax to describe readonly on the outside, writeable on the inside for a given property, so we can avoid making a getter just for this purpose (or using any of the convoluted options linked in that StackOverflow post).

Use Cases

To make this pattern easier to express.

Examples

instead of having to write

class Foo {
  private _foo = 123
  get foo() {
    return this._foo
  }

  changeIt() {
    this._foo = 456
  }
}

const f = new Foo
f.foo = 345 // ERROR

we would be able to write something shorter like

class Foo {
  publicread foo = 123

  changeIt() {
    this.foo = 456
  }
}

const f = new Foo
f.foo = 345 // ERROR

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

[RyanCavanaugh]

Previously at #2845 but we should revisit after so long

[trusktr]

Just a note, but #2845 is similar but different. This one is not about making a getter/setter, but about making only a property, and being able to specify that the property be readonly on the outside of the class, and writable only inside the class (and subclasses too, depending on the keyword used)

Taking the idea a little further:

class Foo {
  // readonly in public code or subclasses, writable in this class only
  publicread privatewrite foo = 123

  // readonly in public code, writable in this class or subclasses
  publicread protectedwrite bar = 123

  // not visible in public code, readonly in subclasses, writable in this class only
  protectedread privatewrite baz = 123
}

and otherwise public is equivalent to publicread publicwrite, protected is equivalent to protectedread protectedwrite, and private is equivalent to privateread privatewrite, where the write specifiers can not be less strict than the read specifiers (or can they?).

[woubuc]

I'd love this feature in Typescript. It would allow me to simplify so many of my classes, especially in libraries and packages that expose a public API.

I'm not a huge fan of the publicread privatewrite syntax proposed by @trusktr as those keywords feel a little 'forced' to me. How about using the existing readonly keyword and allowing multiple access modifiers in increasing order of specificity (public > protected > private). Access is then resolved from right to left, with the first matching access modifier defining the access level and readonly status:

// Seen as `private foo` by class members
// Seen as `public readonly foo` by other code
public readonly private foo : Foo;

// Seen as `private foo` by class members
// Seen as `protected readonly foo` by subclass members
// Not accessible by other code
protected readonly private foo : Foo;

// Seen as `protected foo` by class and subclass members
// Seen as `public readonly foo` by other code
public readonly protected foo : Foo;

// Would technically be valid as well, though not very useful
// Seen as `private readonly foo` by class members
// Seen as `protected foo` by subclass members
// Seen as `public readonly foo` by other code
public readonly protected private readonly foo : Foo;

// Throws an error on compile, since the `private` modifier is more specific than `public`
private public readonly foo;

The upside of this would be that we don't introduce new keywords, and the syntax is flexible enough in case other modifiers like readonly are added.

A downside would be that function signatures like these are a little harder to parse visually when reading the code. But then the same could be said for everything that adds more keywords.

A question here would be how to handle the 'no access modifier = public' rule that Typescript uses. Should the public modifier be required for signatures with multiple access modifiers, or would the following also be valid?

readonly private foo : Foo;

I'd argue that this could get confusing (was this intentional or did someone mix up the order of keywords?) so I think an explicit public modifier should be required.

Note: this is written by someone who has no knowledge of the Typescript compiler or language design in general. So I don't know how easy/difficult/impossible this would be to implement. I'm curious to get some feedback on the syntax and on why this is or isn't a good idea.

[robbiespeed]

Just encountered a use case for this today when writing out a value ref class.

class Ref <T> {
  readonly value: T;
  constructor (value: T) {
    this.value = value;
  }
  set (value: T) {
    this.value = value; // errors unless I override the type of `this`
    return value;
  }
  // ...
}

Overriding the type of this, can get annoying fast if you have lots of methods that need write access.

There are other ways around it like storing the value in a private field then creating a getter, but that adds a performance penalty.

@trusktr It might be best to default reads to always be public.

// Seen as `private foo` by class members
// Seen as `public readonly foo` by other code
privatewrite foo: string

This goes along with how typescript works now, fields are by default public and you narrow their scope using private or protected. My guess is it would also be easier to accommodate most cases without the need to explicitly define both read and write.

Also here's how I am getting around this issue right now. It's a bit cumbersome, but maybe it will help out others who desire this feature.

type Writeable <T> = {
  -readonly [P in keyof T]: T[P];
};

type WritebaleRef <T> = Writeable<Ref<T>>;

class Ref <T> {
  readonly value: T;
  constructor (value: T) {
    this.value = value;
  }
  set (this: WritebaleRef<T>, value: T) {
    this.value = value; // no error because `this` type is changed to WritebaleRef<T>
    return value;
  }
  // ...
}

[yvbeek]

This is one of the features I miss so much in TypeScript.

I don't really like the publicread privatewrite notation. Is there an other language that uses that notation?

Here are a few suggestions:

// Option 1: C# style
public name: string { get; private set; }

// Option 2: Swift style
private(set) name: string

// Option 3: Swift struct-style
public readonly name: string

mutating changeName(name: string) {
  this.name = name
}

// Option 4: New keyword
public frozen name1: string
public readonly name2: string

My choice would be the Swift style (option 1) or C# style (option 2). Option 3 is for if we can't change the property definition.

[woubuc]

I also like the C# syntax but I think it's too far from the way getters and setters are defined in JS/TS so it would look out of place. Swift syntax looks nice though.

[trusktr]

Neat to know how other languages do this.

@woubuc Your idea is great if we need to prevent from adding new keywords.

With the new keywords I suggested we can do things like

publicwrite protectedread privatewrite foo = 123

which makes foo writable only in public and private code, but not in subclasses (it could be a valid use case, f.e. "I want this class to handle user input for foo, but I don't want subclasses to interfere with user input of foo, while the subclasses can still extend functionality in other areas").

@woubuc How would we specify the same thing with the space-separated existing keywords? Would it be

public protected readonly private foo = 123

?

Also with the new keywords, order wouldn't matter (or at least, the intention is clear regardless of order):

privatewrite protectedread publicwrite foo = 123

Here's my attempt with the existing keywords:

private protected readonly public foo = 123

But with the new keywords, what would happen if someone tries to use the existing keywords?:

privatewrite protectedread protected publicwrite  foo = 123

Perhaps they'd need to be mutually exclusive, so we can either use only the existing keywords, or only the new ones, but not both.

[whzx5byb]

The Readonly<T> generic type (or an interface) will do the "public readonly, private writable" pattern.

interface IFoo {
  readonly foo: number
}
class Foo implements IFoo {
  foo = 123

  changeIt() {
    this.foo = 456
  }
}

const f: Readonly<Foo> = new Foo
const g: IFoo = new Foo

[yvbeek]

@whzx5byb I appreciate your example, but it is not a solution to the problem.

1. the compiler would still allow me to create an instance of Foo and then set the foo variable
2. this forces the developer to use interfaces instead of classes
3. this becomes impractical in more complex constructs like inheritance

[paul-marechal]

I'm not sure overly precise granularity is useful if it makes us write crazy things to define properties?

I think something simple like the following would do the trick:

class Foo {
  /**
   * foo can be read from public, protected and private contexts,
   * writable only within the class and its subclasses.
   */
  public protected foo: number;
}

class Bar {
  /**
   * bar can be read from public, protected and private contexts,
   * writable only within the class.
   */
  public private bar: number;
}

class Buzz {
  /**
   * buzz can be read from protected and private contexts,
   * writable only within the class.
   */
  protected private buzz: number;
}

Adding "larger" modifiers would only expand readability, and writabiIity would be kept to the most restricted modifier. We can finally add the readonly keyword in this word soup to close this last scope and never be able able to write.

edit: Actually you would never need to mix the readonly keyword with more than one access modifier.

I don't really see a case where someone would want it the other way around, like "public read/write and protected readonly".

[trusktr]

"public read/write and protected readonly".

@marechal-p The example I showed above was "public read/write, protected readonly, private read/write". In that concept, this allows the public (end users) to pass data in, and only allows the private scope to have full control (subclasses aren't afforded this).

With your idea (which I do like as a subset and feel that it would already be a lot better than what we currently have), how could we implement similar? Seems impossible.

I think being able to distinguish public input from protected input (in the private scope) could be useful. But I would totally settle with your idea over the current.

[paul-marechal]

In that concept, this allows the public (end users) to pass data in, and only allows the private scope to have full control (subclasses aren't afforded this).

My opinion here is that subclasses should be seen as "end users" hence why I found that this was odd. In your example the field should simply be public (r/w in public/protected/private contexts) because if anyone can change the value from outside then the class private implementations cannot make assumptions about it: it will be mutated by random clients, in public or protected scopes, doesn't matter.

My proposal fits the issue's title "readonly on the outside, writable on the inside" and allows one to avoid the private variable with public getter pattern with minimal syntax modification:

// useless boilerplate, runtime implications:
private _a
public get a() {
    return this._a
}

// less runtime shenanigans
public private a

It is my belief that doing like your example proposes and having "public r/w, protected read-only, private r/w" is unsound. I have a hard time imagining an API design that would need such specificity, and I would assume the design itself needs to be changed.

[snarfblam]

It is my belief that doing like your example proposes and having "public r/w, protected read-only, private r/w" is unsound. I have a hard time imagining an API design that would need such specificity, and I would assume the design itself needs to be changed.

Protected read-only and yet public read/write is an oxymoron. I have to imagine public accessibility must be a strict subset of protected accessibility, which in turn must be a strict subset of private accessibility. Anything else is, on a conceptual level, unenforceable (e.g. you can easily and unintentionally circumvent such an access restriction via helper function).

As far as syntax, I'm not a huge fan of public private myProperty. I think the word readonly should be in there since that's what we're dealing with. I'd vastly prefer what @woubuc suggested. This reads more naturally and clearly.

    // Publicly read-only, otherwise protected.
    public readonly protected foo: Bar;

    // Protected read-only, otherwise private.
    protected readonly private foo: Bar;

[Griffork]

👍 for this, and I like the swift style as the most readable (it's also not too verbose).

Putting multiple of the same modifier in a row, as public private or public readonly private is a recipe for disaster imo.
My problems with this are:

• There's no way people would understand what's written unless they read the specific section in the docs that discribes what multiple public/private modifiers mean.
• It's different to convention in other languages.
• This syntax would be really hard to google or ask questions for because search results for public, protected and readonly modifiers standalone would be returned as priority.

Reasons I like the swift style:

• As someone mentioned the C# style is different enough from the way getters and setters are specified to make it confusing for new coders, particularly those that have used C# before (do I use get() or {get()} to make a getter, I've seen both in use?).
• private(set) very obviously does something different to private so it's easier to pick up on possible access level problems at a glance. public readonly private can easily be mistaken for public readonly which does something quite different.
• private(set) Gives a pretty good indication of what it's doing if you've never seen the syntax before, and you can be super explicit with public(get) private(set) if you're working with people that don't commonly use typescript.
• private(set) is less verbose than public private or public readonly private (not really a big deal for me, but some people care about this).

The downsides to using the swift style is that private(get) property would be an alias for private readonly property (not a big problem, but slightly confusing for new coders).

[snarfblam]

Putting multiple of the same modifier in a row, as public private or public readonly private is a recipe for disaster imo.
My problems with this are:

* There's no way people would understand what's written unless they read the specific section in the docs that discribes what multiple public/private modifiers mean.

public private seems confusing for obvious reasons. public readonly private might give you a moment of "heywhat" the first time, but I only see one way you can reasonably interpret it. If you guess, you may not feel confident in your guess, but it will almost certainly be correct. As far as googling it, anyone trying to program should have the know-how to use quotes with Google. (Guess what the very first result for "public readonly private" is.)

Nonetheless, it may not be ideal. Just my personal preference. There are plenty of other options. public get private set seems pretty straightforward to me. I do grimace at suggestions involving punctuation. Javascript already tends to get dense with parens and braces. The further you move from having them depict the structure of your logic, the harder everything is to parse. Not to mention Google tends to ignore punctuation in searches, even inside quotes.

[SrBrahma]

This is one of the features I miss so much in TypeScript.

I don't really like the publicread privatewrite notation. Is there an other language that uses that notation?

Here are a few suggestions:

// Option 1: C# style
public name: string { get; private set; }

// Option 2: Swift style
private(set) name: string

// Option 3: Swift struct-style
public readonly name: string

mutating changeName(name: string) {
  this.name = name
}

// Option 4: New keyword
public frozen name1: string
public readonly name2: string

My choice would be the Swift style (option 1) or C# style (option 2). Option 3 is for if we can't change the property definition.

I think the 2nd one is really good and wouldn't break existing code and it basically don't add new keywords.

This issue should really be worked on.

[grind-t]

If you perform a cast, then the value can be changed (playground), although it looks a little strange.

[mixtur]

...public accessibility must be a strict subset of protected accessibility, which in turn must be a strict subset of private accessibility

This shaped the following model in my head

If you add to the cited prospsition that allowing write implies allowing read you can make a list like this. Here every "capability" below "code" is alowed and everything above is forbidden

capability	code
	public
public write
	public(get)
public read
	protected
protected write
	protected(get)
protected read
	private
private write
	private(get)
private read

[paul-marechal]

@mixtur So would your proposition look like the following?

class Foo {
    public(get) protected name: string;
}

[mixtur]

@marechal-p

@mixtur So would your proposition look like the following?

class Foo {
   public(get) protected name: string;
}

No. Just

class Foo {
    public(get) name: string;
}

This would mean that the only forbidden thing is public write.

Ow. I see your point.
So one actually might want to forbid writing from both protected and public, but allow reading for everyone.

[paul-marechal]

@mixtur my point was just to see how it plays out... To expand more: with your notation, if we want something to be protected but allow reading from public we would just write public(get) and nothing more? Felt weird to omit the protected keyword.

[mixtur]

More than two keywords feels noisy.

I though about it and I was actually wrong with my model. It doesn't work like a "list". I drew this chart. Cases 4 and 5 are falling out of the list representation.

So according to this I suggest

case 1 - public(get)
case 2 - protected(get)
case 3 - private(get)

cases 4 and 5 I think are rare so it is fine for them to require more noisy syntax.

case 4 - public(get) private(set)
case 5 - protected(get) private(set)

[robbiespeed]

cases 4 and 5 I think are rare so it is fine for them to require more noisy syntax

@mixtur case 4 is what inspired this proposal, so I disagree that it would be rare I think it would be the most used of any of the new cases, followed by case 1, then 2.

Case 3, and 5 already have working syntax:
case 3 - private readonly
case 5 - protected readonly

My syntax suggestion for the additional cases would be:
case 1 - protected read(public)
case 2 - private read(protected)
case 4 - private read(public)

Where read([public|protected]) must follow [protected|private] similar to readonly but instead of removing write privilege it elevates read.

Case 1 and 4 could be further simplified if read implied read(public):
case 1 - protected read
case 4 - private read

[Griffork]

A bit out of the scope of this thread, but it'd be great to be able to apply protected write to module variables as well, so they're readonly externally but can be altered internally.

[ExE-Boss]

Note that exported module variables are already protected write when using native ES modules, since the module namespace exotic object behaviour provides a read‑only view of the exported variables.

[snarfblam]

That applies to the exported variables themselves (i.e. the exported reference to the class definition). That's unrelated to instance and static properties of a class.

[thw0rted]

I don't understand the argument against @paul-marechal 's suggestion. The chart from back in January is very straightforward. We already have public | protected | private {readonly} which covers 6 of the 9 cases. The other 3 cases are trivially solved with two modifiers ordered with broader access before narrower -- public protected, public private, protected private. If we assume that write implies read, and narrower access is never more restricted than a broader one, these sequences must mean "public read, protected write", "public read, private write", and "protected read, private write" respectively.

There are other issues to argue about a writeonly keyword; I don't think we're going to get it any time soon. Likewise, I don't think anybody has made a realistic argument in favor of public-write / protected-readonly. I see @trusktr took a stab at it, but he's actually talking about getters and setters -- providing the appearance of a read/write property through a public API. That's also a different issue (Ryan linked it near the top of the thread), this is specifically for "plain" property definitions.

[trusktr]

@ifeltsweet

All other variations like privateread would be quite unnecessary in my opinion and are solving for a completely different use case than what was originally requested by this issue.

It is not unnecessary, but actually useful. It's about semantics: I want to define something that I can read from, but I want only the outside to modify it. I want it to be explicitly an input only.

There are real world use cases I already pointed out, but here is another one: props in various frameworks like React, Vue, Solid, etc, are usually meant to be readonly on the inside, despite that some of these libs' runtimes allow modifying input props (and their documentation highly recommends not to modify props despite that you can, and some even spit warnings to console in dev mode).

Again, this isn't about technicality, this is about expression of intent.

Writable on the outside, readonly on the inside, is totally valid, and real-world practice. We simply need to make the language to describe actual real-world code.

[thw0rted]

@trusktr see my comment above about "providing the appearance of read/write". Public write / private read is a relatively rare use case -- important to describe a limited number of frameworks. It's not a design pattern for everyday use, not something to be encouraged, and should be implemented via property accessors anyway.

I would contend that it's more important to have a one-line shorthand for write-implies-read cases. Note that this was your original use-case in the OP, private _foo: string; public get foo(): string { return this._foo; } etc. Then, write-without-read cases could be described via variant accessors -- public set foo(x: string); private get foo(): string; -- mirroring the actual implementation.

In case they're not already linked from here, other issues to follow for differing accessor modifiers and writeonly: #21759, #30852, #43662 , #45517.

[infacto]

Please no keywords like publicread, privatewrite or protect dread? (protectedread). It's hard to read and just looks ugly. I prefer more the Swift way. Get schwifty. private(set) or public(readonly)? To limit readonly only for public. The solution should be bulletproof. And in best case no breaking changes. ...

[thw0rted]

I agree that the compound words are ugly but TS is based on JS / ES, not Swift, and has no other cases where a modifier uses function-like syntax similar to what you've linked. I believe that there are combinations of existing reserved words, in an order that is currently a syntax-error (and thus shouldn't be a breaking change!), which would suffice to implement this feature.

[ifeltsweet]

After going through the protectedwrite proposal (which already satisfies my needs) I think another possible future addition would be a privatewrite modifier as suggested by @robbiespeed.

These write modifiers play well with the standard access modifiers public, private, and protected and from my point of view are very easy to reason about.

class Order {
  // Can write from this class only, read from anywhere
  privatewrite price: number;

  // Same as above, but explicit public access
  public privatewrite price: number;

  // Accessable from this class and subclasses, writable only from this class
  protected privatewrite price: number;

  // Compiler/linter warning because privatewrite has no effect
  private privatewrite price: number;

  // Compiler error because readonly conflicts with privatewrite
  readonly privatewrite price: number;
}

[dhoulb]

Feel like this suggestion is blocked because of we haven't found a syntax people love, so throwing another option into the ring:

Overloading

Undo the requirement that members must have identical modifiers, and embrace the modifiers being different:

class Dog {
    public readonly name: string;
    private name: string = "abc";
}

class Cat {
   protected readonly _age: number;
   private _age: number = 123;
}

The separate modifier overloads are collapsed together and tested against based on where the access is happening. Only one override can set a default value. Remove the duplicate identifier warning, but add a warning if overloads are not adjacent (same as method overloads).

[thw0rted]

I like this idea because it reinforces the notion that access modifiers, like function parameter types, are a type-space construct. I'm not clear on your Cat example though - what does it mean to have two protected declarations?

[Jet132]

Feel like this suggestion is blocked because of we haven't found a syntax people love, so throwing another option into the ring:

Overloading

Undo the requirement that members must have identical modifiers, and embrace the modifiers being different:

class Dog {
    public readonly name: string;
    private name: string = "abc";
}

class Cat {
   protected readonly _age: number;
   protected _age: number = 123;
}

The separate modifier overloads are collapsed together and tested against based on where the access is happening. Only one override can set a default value. Remove the duplicate identifier warning, but add a warning if overloads are not adjacent (same as method overloads).

That would be like my suggestion at #43553 which also has the benefit of supporting stricter types for broader access scopes.

[mmichaelis]

I like this idea because it reinforces the notion that access modifiers, like function parameter types, are a type-space construct. I'm not clear on your Cat example though - what does it mean to have two protected declarations?

Similar thoughts on this one. Regarding the Cat example, it needs to be decided, if it has any relevance at all, or if it should rather be an error reported at compile time. The behavior is hard to predict (can the subclass now modify the value or not?), thus, I would rather suggest a compile-time error.

Suggestion for compile-time error: I think, as a rule of thumb, the readonly part must always have higher visibility than the writable part. Otherwise, a compile-error should be reported.

[dhoulb]

I'm not clear on your Cat example though - what does it mean to have two protected declarations?

Thanks! That was a typo. Second one should've been private. I've updated the code.

[khokm]

I think the best way to implement this is a possibility to add different types for each access modifiers.
This will be useful for mutable properties like arrays, map and sets.

//foo is readonly in public, but can be changed by this and derived classes.
public readonly foo : number;
protected foo : number;
private foo : number;

//other classes can't add items to `data`, but current class can.
public readonly data: ReadonlyMap<string, number>;
private data : Map<string, number>;

[sviat9440]

public readonly foo : number;
protected foo : number;
private foo : number;

If property has an initializer, where should I pass it in your example?

foo: number = 123;

[khokm]

public readonly foo : number;
protected foo : number;
private foo : number;

If property has an initializer, where should I pass it in your example?

foo: number = 123;

I think it shouldn't be matter, just use one of them.

[zkulbeda]

Hi. There is a tc39/proposal-grouped-and-auto-accessors that suggested syntax for read-only field, but using same syntax as ECMAScript private fields. This will be compatible with ECMAScript decorators currently being worked on for TS 5.0 #48885

// code from proposal
class C {
  accessor a = 1;                   // same as `accessor a { get; set; } = 1;`
  accessor b { } = 1;               // same as `accessor b { get; set; } = 1;`
  accessor c { get; set; } = 1;     // same as `accessor c = 1;`
  accessor d { get; } = 1;          // getter but no setter
  accessor e { set; } = 1;          // setter but no getter (use case: decorators)
  accessor f { get; #set; };        // getter with private setter `#f`;
  accessor g { #set; } = 1;         // private setter but no getter (use case: decorators)
  accessor #h = 1;                  // same as `accessor #h { get; set; } = 1;`
  accessor #i { } = 1;              // same as `accessor #i { get; set; } = 1;`
  accessor #j { get; set; } = 1;    // same as `accessor #j = 1;`
  accessor #k { get; } = 1;         // getter but no setter
  accessor #l { set; } = 1;         // setter but no getter (use case: decorators)
}

So, I suggest just add access modifiers into brackets like this:

accessor a { get; protected set; };
accessor b { get; private set; };
accessor c { 
  get() { ... } 
  protected set(value) { ... }
};

[snarfblam]

That looks great as far as accessor properties are concerned but this thread is largely concerned with data properties.

[dhoulb]

@sviat9440 There are two options, it could work exactly as overloads on functions do right now, so you'd declare the implementation last (and independently) like this:

public readonly foo: ReadonlyMap<string, string>;
private foo: Map<string, string>;
foo = new Map<string, string>();

Second option is to combine an overload signature and an implementation. This would be slightly different to how overload functions work now (but slightly more convenient), because if an overload signature exists the base signature of the function is not used outside the implementation.

public readonly foo: ReadonlyMap<string, string>;
private foo: Map<string, string> = new Map();

The implementation should be last for style reasons, but it shouldn't be enforced (otherwise ESLint would probably generate an no-redeclare error but TS itself shouldn't care).

All signatures should be adjacent or TS generates a should be adjacent error.

Signatures must be compatible with the implementation or TS generates a must be compatible error.

Having a second implementation would make TS generate a no same property error as it does right now.

[LongTengDao]

@dhoulb go idea

I think force add declare keyword would be more safe:

declare protected foo :number;
private foo :number = 1;

At least forbid to write assignment not at last to avoid:

private foo :number = 1;
protected readonly foo :number;

being transformed by old type eraser util to:

foo = 1;
foo;

which cause runtime 1 disappear bug.

[TheCymaera]

Feel like this suggestion is blocked because of we haven't found a syntax people love, so throwing another option into the ring:

Overloading

Undo the requirement that members must have identical modifiers, and embrace the modifiers being different:

class Dog {
    public readonly name: string;
    private name: string = "abc";
}

class Cat {
   protected readonly _age: number;
   private _age: number = 123;
}

The separate modifier overloads are collapsed together and tested against based on where the access is happening. Only one override can set a default value. Remove the duplicate identifier warning, but add a warning if overloads are not adjacent (same as method overloads).

I like this as it's common to expose a sub-class publicly.

class Example {
    public readonly data: ReadonlyMap<string, string>
    private readonly data: Map<string, string>
    
    // ...
}

Also lets us hide function parameters:

class Example {
    public readonly doStuff()
    private readonly doStuff(hiddenOption)
    doStuff(hiddenOption) {
        // do stuff
    }
}

This also has the benefit of not introducing new keywords.