Different types based on visibility

[Jet132]

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]

Not only do I want to make some properties be readonly when accessed publicly but I also want them to change their type. For example from Array to ReadonlyArray or from Map to ReadonlyMap. There will most likely need to be restrictions on how different those types can be. Like the more visible types need to be more open than the least visible type and only the least visible type can be writeable.

Though those might sound like quite strict rules they are applicable to most common use cases (at least for me) where you want to secure the mutability of a property.

[paul-marechal]

There will most likely need to be restrictions on how different those types can be. Like the more visible types need to be more open than the least visible type and only the least visible type can be writeable.

@Jet132 For sure such constraints will have to be met.

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

private prop1: string;
public prop1: number;

@MartinJohns the example you wrote should result in an error because string is not compatible with number. Like the type 'abc' is compatible with string, but string is not compatible with 'abc'. The same constraints should be respected where more closed declarations must be compatible with more opened ones.

[paul-marechal]

Although thinking about it more, there is something odd, see:

class {
    private prop: 'abc'
    public prop: string
}

In such a case, the public member can be assigned any string, violating the private 'abc' constraint. Does that mean that both types have to either be the same to be mutable settable, and if different more open declarations must be readonly?

[Jet132]

If you look at my first comment I actually suggested only having the least visible type be mutable. I'll change the issue proposal to fit it

[paul-marechal]

I had missed it, good to mention it in the proposal.

Another question is where would initialization be done? Only on the least visible type? Should the declaration order matter?

class {
    private prop = 'abc' as const
    public readonly prop: string
}

[Jet132]

The initialization should be done in the least visible type and about the declaration order, I'm not sure but it should matter for readability. We can think of the more visible types like function overloads just for visibility. Would it then make sense to order it from most to least visible to have the initialization at the bottom?

[paul-marechal]

Would it then make sense to order it from most to least visible to have the initialization at the bottom?

Sounds good to me at least. Like you said it would be similar to functions overloads.

class {
    public readonly prop: IThing
    private prop: Thing = new Thing()
}

Lastly, what would it mean to declare all 3 scopes?

class {
    public readonly prop: '?'
    protected readonly prop: '??'
    private prop: '???'
}

[MartinJohns]

having the least visible type be mutable

TypeScript has no way to declare types as mutable / immutable. This would require something like #17181.

[robbiespeed]

If the ergonomics were improved for the cases where the value type doesn't change between access levels, then I would prefer this proposal over #37487. One suggestion, is if the value type was implicit for following declarations of the same property.

class Foo {
  public readonly prop: string;
  private prop; // inferred as string 
}

If you look at my first comment I actually suggested only having the least visible type be mutable. I'll change the issue proposal to fit it

@Jet132 rather than requiring that only least visible is mutable which would really limit the usefulness of this proposal, what if types were constrained at mutation to use a intersection of all types across access levels.

class Foo {
  public prop: string;
  private prop: 'abc';
}
const foo = new Foo();
foo.prop = 'abc'; // prop is constrained to ('abc' & string) which results in 'abc'
foo.prop // type is still string

This would be helpful in handling non primitives as well.

class Box <T> {
  public readonly value: T;
  private value;
  constructor (value: T) {
    this.value = value;
  }
  set (value: T) {
    this.value = value;
  };
}
interface ReadonlyBox <T> {
  readonly value: T;
}
class Foo {
  public prop: ReadonlyBox<string>;
  private prop: Box<string> = new Box();
}
const foo = new Foo();
foo.prop = { value: 'abc' }; // TypeError because it doesn't satisfy (Box<string> & ReadonlyBox<string>)

This eliminates the risk that prop could be replaced with a less capable object which would cause errors when a Box attempts to use the set method inside the Foo class.

[paul-marechal]

TypeScript has no way to declare types as mutable / immutable.

@MartinJohns I think we used the wrong terminology, we meant changing the value of the property. By "non-mutable" what we meant was "non-settable" as in prefixing with readonly.

[paul-marechal]

class Foo {
  public prop: string;
  private prop: 'abc';
}
const foo = new Foo();
foo.prop = 'abc'; // prop is constrained to ('abc' & string) which results in 'abc'
foo.prop // type is still string

@robbiespeed this means leaking implementation details and breaking encapsulation? I am not in favor of this. Whenever you want to change implementation details, what is effectively used publicly might break.

Although I'd be fine with the type inference.