Variant accessors

[RyanCavanaugh]

Getter / Setter Variation

Implements #2845 and #2521

Overview

This implements two related features:

• The ability to have getter and setter pairs differ in their visibility modifiers (Different access modifier for getter and setter #2845, [feature] class properties that are "readonly in public, writable in private" or other permutations #37487 but not for fields)
• The ability to have getter and setter pairs differ in their types (Suggestion: allow get/set accessors to be of different types #2521)

Differing Types

Property getters and setters may now differ in their types:

const thing = {
    _size: 0,
    get size(): number {
        return this._size;
    },
    set size(value: string | number) {
        this._size = typeof value === 'string' ? parseInt(value) : value;
    }
}

// OK
thing.size = "100ish";
// OK
console.log(thing.size.toFixed(2));

Restrictions

As a conservative implementation, a few restrictions are in place.

First, the type of the getter must be assignable to the type of the setter. In other words, the assignment

obj.x = obj.x;

must be legal assuming obj.x is writable at all.

This restriction closes off a certain set of use cases for properties that start out "uninitialized" (usually null/undefined) but then only want "initalizing" assignments to occur. We'll continue to examine these to see if those use cases are prevelant enough to warrant opening this up more.

These prevent novel unsoundness from occurring and makes this feature unimpactful from a type relational perspective, which limits its risk.

Differing Visibility

In classes, set accessors may now be less visible than their corresponding get accessor. It looks like this:

class MyClass {
    get size(): number {
        // TODO: implement
        return 0;
    }
    protected set size(value: number) {
        // TODO: implement
    }

    grow() {
        // OK
        this.size++;
    }
}

let c = new MyClass();
// Error, can't write to 'size' outside of 'MyClass'
c.size = 10;
// OK
console.log(c.size);

Type Relationship Effects

TL;DR: there are none

TypeScript is already covariant when relating properties of types. The unsoundness of this is straightforward to demonstrate during aliased writes:

type Alpha = { x: string | number };
type Beta = { x: string };

function mutate(ref: Alpha) {
    ref.x = 0;
}
const p: Beta = { x: "hello" };
mutate(p);
// Prints 'number' on a binding typed as 'string', oops.
console.log(typeof p.x);

TypeScript also already ignores the readonly modifier when relating types, so the protected or private state of a setter does follows the same pattern.

Caveats

TL;DR: The type system remains entirely covariant in other operations! This has some effects that may not be immediately apparent.

Types with variant getters/setters are effectively reduced to their get side when put through mapped types:

// Setter types are intentionally not preserved
// through mapped types or other transforms; they
// are specific to their originating declaration
declare const CoercingThing: {
    get size(): number;
    set size(v: number | string);
}
type PCT = Partial<typeof CoercingThing>;
declare const pct: PCT;
// Not OK
pct.size = "hello";

This is fairly straightforward to reason about -- a mapped type usually represents a "copy with transform" operation, e.g.

(psuedocode: some type operation f applied to an object type obj)
result = { }
for k in keyof obj
  result[k] = f(obj[k]);
return result

In other words, for an arbitrary mapped type, we have no idea how its actual value is produced, and the only sound assumption is that this type doesn't copy over any coercing semantics from its setters.

The same applies to lookup types -- the type T[K] still means *the read type of K on T. A free setter function can't be used to indirectly access the coercing side of the setter:

declare const CoercingThing: {
    get size(): number;
    set size(v: number | string);
}
function setter<T, K extends keyof T>(obj: T, key: K, value: T[K]) {
    obj[key] = value;
}
// Not OK, even though CoercingThing.size = "100" is OK
setter(CoercingThing, "size", "100");

[RyanCavanaugh]

@typescript-bot pack this

[typescript-bot]

Heya @RyanCavanaugh, I've started to run the tarball bundle task on this PR at 6f09705. You can monitor the build here.

[typescript-bot]

Hey @RyanCavanaugh, I've packed this into an installable tgz. You can install it for testing by referencing it in your package.json like so:

{
    "devDependencies": {
        "typescript": "https://typescript.visualstudio.com/cf7ac146-d525-443c-b23c-0d58337efebc/_apis/build/builds/93799/artifacts?artifactName=tgz&fileId=3EC3DF89823D37BAFB0102D05E0C5878E1CC64D470DA739FA701667C9C8CEEC602&fileName=/typescript-4.2.0-insiders.20210120.tgz"
    }
}

and then running npm install.

---

There is also a playground for this build and an npm module you can use via "typescript": "npm:@typescript-deploys/pr-build@4.2.0-pr-42425-2".;

[RyanCavanaugh]

@typescript-bot pack this

[typescript-bot]

Heya @RyanCavanaugh, I've started to run the tarball bundle task on this PR at d2affa2. You can monitor the build here.

[typescript-bot]

Hey @RyanCavanaugh, I've packed this into an installable tgz. You can install it for testing by referencing it in your package.json like so:

{
    "devDependencies": {
        "typescript": "https://typescript.visualstudio.com/cf7ac146-d525-443c-b23c-0d58337efebc/_apis/build/builds/94491/artifacts?artifactName=tgz&fileId=5D2DE7C1D3D1A47BE543A3A8978BBC0D64E3E7103505294FB8EDC8B577A31AA302&fileName=/typescript-4.2.0-insiders.20210129.tgz"
    }
}

and then running npm install.

---

There is also a playground for this build and an npm module you can use via "typescript": "npm:@typescript-deploys/pr-build@4.2.0-pr-42425-5".;

[ExE-Boss]

This probably also fixes #32821

[trusktr]

What milestone will this go into?

[RyanCavanaugh]

@typescript-bot pack this

[typescript-bot]

Heya @RyanCavanaugh, I've started to run the tarball bundle task on this PR at b7f93bb. You can monitor the build here.

[typescript-bot]

Hey @RyanCavanaugh, I've packed this into an installable tgz. You can install it for testing by referencing it in your package.json like so:

{
    "devDependencies": {
        "typescript": "https://typescript.visualstudio.com/cf7ac146-d525-443c-b23c-0d58337efebc/_apis/build/builds/99188/artifacts?artifactName=tgz&fileId=8A4F5CF4310E72AE3F3599DB677A807009BC386229856DAD4B06C74D77071B7702&fileName=/typescript-4.3.0-insiders.20210325.tgz"
    }
}

and then running npm install.

---

There is also a playground for this build and an npm module you can use via "typescript": "npm:@typescript-deploys/pr-build@4.3.0-pr-42425-10".;

[RyanCavanaugh]

@ahejlsberg thanks, addressed at #43405

[kevinclarkadstech]

@typescript-bot pack this

[pikax]

What's the syntax (if supported) for generic types?

Simplified Example:

type MarkAsString<T extends Record<string, any>> = {
    [K in keyof T]: T extends number ? T[K] /* How to set add a string|number set here? */ : T[K]
}

declare const a: MarkAsString<{ a: boolean, b: number, c: string }>
a.b = '42'; // I want to have this avalible

a.c = '112'

// @ts-expect-error
a.a = '2'

Actual use case

In Vue3 there's Ref<T> (simplified as { value: T}) and Reactive<UnwrappedRef<T>> (unwraps {value: T} to T, recursive)
Basically:

const r = ref({ a: 1} )

r.value.a = 1

const a = reactive(r)
a.a // 1

On a reactive/ref object the set in typescript must be UnwrappedRef<T> which is not true, because when you assign to a reactive it will unwrap the value:

const r = ref({a:1});
const a = ref({
  r
}) // results in `{ r: { a: 1 } }` 

a.r = r; // typescript error  because `r` is `Ref<T>` instead of `UnwrappedRef<T>`, but it works at runtime.

[thw0rted]

I think what you're actually looking for is how to use the new feature with index signatures. My first guess would have been something like

interface ConvertingRecord {
  get [k: string](): string;
  set [k: string](val: string | number);
}

but that doesn't work on the latest Playground for this build. Maybe it's not currently possible?

[RyanCavanaugh]

Yeah, that's a totally separate and additional feature.

[pikax]

Yeah, that's a totally separate and additional feature.

Cool, should I open an issue?

[RyanCavanaugh]

Sure

[V1raNi]

This is very cool, is there any information on which version will have this change?

[yume-chan]

@V1raNi This has been shipped in 4.3 https://www.typescriptlang.org/docs/handbook/release-notes/typescript-4-3.html#separate-write-types-on-properties

[ws93]

The different type for setter doesn't work for Union type as well. Is this expected? Example can be found here

[thw0rted]

@ws93 I didn't see an issue for that yet so I went ahead and opened #45376 .

[V1raNi]

@V1raNi This has been shipped in 4.3 https://www.typescriptlang.org/docs/handbook/release-notes/typescript-4-3.html#separate-write-types-on-properties

Oh, thank you very much. It's just I was interested in different visibility and couldn't find it in the text, and the docs seem to be outdated a bit regarding this part.