[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".