SUGGESTION: more strict checks on write-only properties

[YunHsiao]

Suggestion

🔍 Search Terms

write-only properties
strict type check

✅ 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

Write-only properties have not been the most type-checked area of the language (#21759), but in some cases though we can almost always tell it's not what's intended and throw some error messages in there.

📃 Motivating Example

The example below (playground link here) demonstrates a peculiar case that could definitely benefit from some type error messages, but the suitable situations may go well beyond this simple case and are open for discussion.

class A {
    private _v = [0];

    set v0 (v: number) {
        this._v[0] = v;
    }

    get array (): Readonly<number[]> {
        return this._v;
    }
}

const x = new A();

x.v0 = 10; // correct usage
x.v0 += 10; // incorrect usage (results in NaNs), which should not pass type check!

💻 Use Cases

[FilipeBeck]

It is also allowing const v0 = x.v0 without having accessor method

[andrewbranch]

Duplicate of #21759 (and more directly #30852)—the problem is we don’t recognize this as write-only at all.

[thw0rted]

@andrewbranch would you consider reopening this in light of the introduction of Variant Accessors, or at least include it if/when #43662 comes along? Should we just update that ticket to make sure that the write-only use case is considered?

[andrewbranch]

Seems reasonable to discuss in #43662, and #21759 is still open as well.