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.

没有指定实现文件、测试或入口点。先从作为动机的 TypeScript 示例和链接的控制流分析实现讨论开始，然后确定非 readonly 属性别名的安全规则；完成的标准是示例能够正确收窄，同时不改变生成的 JavaScript，并在适当的地方记录这一限制。