Control flow analysis of aliased conditions is not able to narrow object properties

Suggestion

🔍 Search Terms

• Control flow
• Aliased conditions
• Type narrowing

✅ 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

TypeScript 4.4 added “Control Flow Analysis of Aliased Conditions and Discriminants” which is a great feature, but unfortunately it seems unable to narrow the types on object properties which limits the benefit.

📃 Motivating Example

Take null checks for instance, the following code results in a compiler warning in the AliasedControlFlow-method. The RegularControlFlow method works fine even though it does the exakt same comparison.

interface ITest {
    prop?: string;
}

function AliasedControlFlow(test: ITest) {
    const hasProp = test.prop != null;

    // Object is possibly 'undefined'.
    return hasProp ? test.prop.big() : "";
}

function RegularControlFlow(test: ITest) {
    return test.prop != null ? test.prop.big() : "";
}

💻 Use Cases

This would really help when converting code that is currently not using strictNullChecks as null checks may already be aliased in existing code.

[ahejlsberg]

Is this a use case that is intended to be fixed in the future or is the limitation too much work to resolve?

It’s basically a cost/benefit trade-off in control flow analysis. In order to support mutable properties we’d have to check that there are no assignments to a property between the declaration of the aliased condition that references the property and the check of that aliased condition. It’s possible to do so (anything is possible), but it is non-trivial and it’s not clear the added complexity and potential performance cost is worth it.

[ahejlsberg]

The issue here is that prop is not a readonly property. From #44730, the PR that implemented the feature:

Narrowing through indirect references occurs only when the conditional expression or discriminant property access is declared in a const variable declaration with no type annotation, and the reference being narrowed is a const variable, a readonly property, or a parameter for which there are no assignments in the function body.