Preserve type narrowing of readonly properties of classes for use in closures

[swachter]

🔍 Search Terms

flow typing, type narrowing, closures

✅ Viability Checklist

• 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 isn't a request to add a new utility type: https://github.com/microsoft/TypeScript/wiki/No-New-Utility-Types
• This feature would agree with the rest of our Design Goals: https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals

⭐ Suggestion

Type narrowing of readonly properties of classes should be preserved in closures that are defined after the narrowing.

📃 Motivating Example

We use handler classes that capture events as member properties. When narrowing on the this.event member the narrowed type should be preserved when a closure is created that accesses that member.

type Event = { x: 1, f1: string } | { x: 2, f2: string }

class Handler {
    constructor(readonly ev: Event) {
        switch (ev.x) {
            case 1:
                ev.f1 // ok
                void [].map(() => ev.f1) // ok
                break;
            case 2:
                ev.f2 // ok 
                void [].map(() => ev.f2) // ok
                break;
        }
    }
    process() {
        switch (this.ev.x) {
            case 1:
                this.ev.f1 // ok
                void [].map(() => this.ev.f1) // error
                break;
            case 2:
                this.ev.f2 // ok
                void [].map(() => this.ev.f2) // error
                break;
        }
    }
}

💻 Use Cases

1. This would align flow typing for class members to what flow typing does for local const values or even let values after their last assignment.
2. This would make the current workaround of copying class members into local constants unnecessary.

[MartinJohns]

Duplicate of #51773.

[RyanCavanaugh]

Yep; a derived class can "open up" the readonly at which point the narrowing is no longer sound

class Derived extends Handler {
  ev!: Event;
  constructor(ev: Event) {
    super(ev);
  }
}

[swachter]

Would it be sound for private members?

[typescript-bot]

This issue has been marked as "Duplicate" and has seen no recent activity. It has been automatically closed for house-keeping purposes.