Different types based on visibility

Suggestion

🔍 Search Terms

• Different types based on visibility
• Different types based on private, protected properties

✅ 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

Make properties (and getters/setters) be able to have different types based on where they are accessed from (AKA visibility). It should have the following rules:

• The least visible (relative from where it’s being accessed) type should be used when accessing/setting the property (private over protected over public).
• This should only be a type difference and not change the actual js value that is returned.
• Only the least visible type can be writable.
• The more visible types need to at least include the least visible type.
• Properties can only be initialized on their least visible version
• Types need to be ordered from most visible to least visible

class Foo {
  public readonly prop1: ReadonlyArray<unknown>;
  private readonly prop1: unknown[] = [];
  // Implicitly also means:
  // protected readonly prop1: ReadonlyArray<unknown>;

  public readonly prop2: number;
  protected prop2: number;
  // Implicitly also means:
  // private prop2: number;

  // Error: Only the least visible type can be writeable
  protected prop3: number | string;
  private prop3: number;

  // Error: More visible types need to include the least visible type
  protected readonly prop4: string;
  private prop4: number;

  // Error: Property types need to be ordered from most to least visible
  private readonly prop5: unknown[] = [];
  public readonly prop5: ReadonlyArray<unknown>;

  // Error: Properties can only be initialized on their least visible type
  public readonly prop6: ReadonlyArray<unknown> = [];
  private readonly prop6: unknown[];

  fooMethod() {
    // Works
    this.prop1.push(1);
    // Works
    this.prop2 = 2;
  }
}

class FooBar extends Foo {
  fooBarMethod() {
    // Works
    const length = this.prop2.length;
    // Error: Property 'push' does not exist on type 'readonly unknown[]'
    this.prop1.push(1);
    // Works
    this.prop2 = 2;
  }
}

const foo = new Foo();
// Works
const length = foo.prop2.length;
// Error: Property 'push' does not exist on type 'readonly unknown[]'
foo.prop1.push(1);
// Works
const prop2Value = foo.prop2;
// Error: Cannot assign to 'prop2' because it is a read-only property.
foo.prop2 = 2;

📃 Motivating Example

It removes the need of using custom public/protected getters back by protected/private properties reducing a lot of clutter and repetitive “dumb” code when implementing a strictly typed API.

💻 Use Cases

What do you want to use this for?

Class APIs where you can see the inner state but may only mutate it through the provided method calls.

What workarounds are you using in the meantime?

Getters backed by properties prefixed with _.

class Foo {
  private _prop: number;
  get prop(): number {
    return this._prop;
  }
}

[MartinJohns]

It sounds like you want #37487.

Otherwise this proposal strikes me as really odd. How would this behave?

private prop1: string;
public prop1: number;

[Jet132]

hmm tbh, I would rather keep the order from most to least visible. It’s more consistent with function overloads and also gives a visual indication of how the feature works. Like any not specified visibility just implicitly inherits that from the above (if there is one).

class Foo {
  public readonly prop;
  // protected readonly prop;
  private prop = 1;
}

Maybe we should consider leaving out the type-inference to be even more consistent with function overloads and also with typescript’s tendency to infer from left to right, top to bottom.