Allow non-readonly properties to be used in aliased conditional expressions

Suggestion

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.

🔍 Search Terms

aliased conditional expressions condition control flow readonly property

⭐ Suggestion

Some beta feedback. I was excited to try out TypeScript 4.4 because it provided control flow analysis of aliased conditions but was disappointed to learn that it only works for readonly properties as mentioned in the implementation PR. I get the justification; unfortunately, I don’t use readonly because I don’t think the weak immutability guarantees which the modifier provides are worth the syntax noise or annoying assignability errors.

📃 Motivating Example

I digress. Limiting control flow analysis to readonly properties makes code like the following not work, which I would argue is somewhat surprising.

interface A {
  prop: string | undefined;
}

declare const a: A;
// this works
if (a.prop !== undefined) {
	const b: string = a.prop;
	console.log(b);
}

const hasProp = a.prop !== undefined;
// this errors
if (hasProp) {
	const b: string = a.prop;
	console.log(b);
}

💻 Use Cases

I just want to write code which can take advantage of aliased property checks without having to use the TypeScript’s readonly modifier.

Maybe we could assume some basic things about JavaScript object properties for the sake of developer experience. For instance, we could assume that non-getter property test aliases are safe to use in control flow analysis so long as the property is not directly reassigned.

In any case, I think adding this caveat to blog posts and all marketing copy describing the feature would be wise, because I will likely not be the last person to be confused by this limitation, and many TypeScript features are only documented in release notes.

No implementation file, test, or entry point is named. Start with the motivating TypeScript example and the linked control-flow analysis implementation discussion, then determine the safe rules for aliases of non-readonly properties; done means the example narrows correctly without changing emitted JavaScript and the limitation is documented where appropriate.