-
Notifications
You must be signed in to change notification settings - Fork 12.8k
Require optional chaining for any
type property access.
#53438
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Does not directly address, but would reduce the need for #13219. |
That is the very purpose of I think your suggestion might be better suited as a linter rule. |
You can represent this type today if that's your goal: interface SafeRecord {
[s: string]: SafeRecord;
};
declare let q: SafeRecord;
const m = q?.r?.s?.t; |
This issue has been marked as "Declined" and has seen no recent activity. It has been automatically closed for house-keeping purposes. |
This should be: interface SafeRecord {
[s: string]: SafeRecord | undefined;
}; eg. interface SafeRecord {
[s: string]: SafeRecord | undefined;
};
declare let q: SafeRecord;
const m = q?.r?.s?.t?.u?.v?.w?.x?.y?.z?.a;
// inline use of typeof doesn't work, so you need to define a type guard
const IsString = (s: unknown): s is string => typeof s === "string";
const IsNumber = (s: unknown): s is number => typeof s === "number";
if (IsString(m)) {
console.log(`m is a string: ${m} `);
}
else if (IsNumber(m)) {
console.log(`m is a number: ${m} `);
}
else {
console.log("m is not a string or a number ");
} |
If you want this behavior, surely you should have |
Uh oh!
There was an error while loading. Please reload this page.
Suggestion
Alternative title: "Require checked index access on any"
Require optional chaining for property access on
any
typed values, possibly behind an extra flag or as a modification to thenoUncheckedIndexedAccess
flag.🔍 Search Terms
property access unknown optional chaining any strict checked index
✅ Viability Checklist
My suggestion meets these guidelines:
⭐ Suggestion
Currently, the
any
type allows any operation, even unsafe ones that may throw at runtime. The alternative isunknown
which enforces checking, but is cumbersome to the point that it is often cast without sufficient checking, which is easy to do with type predicates or simply usingas
.Adding an option to require optional chaining when accessing properties of an
any
value would remove one of the largest bug surface areas.A previous proposal was made 2 years ago to allow optional chaining on
unknown
values: #37700. This was rejected, and while I don't fully agree with the reasoning, I can see why it could be seen as incorrect. I believe requiring optional chaining forany
solves the same problem, while addressing the concerns in that proposal.📃 Motivating Example
In vanilla JS, I would expect to see lots of optional chaining to defer type checking to the "leaf" node that is important. This change would check for good hygiene on a similar pattern in TS where a value is
any
.A currently unsafe case in TS is JSON.parse, which returns an
any
value that can lead to runtime failures. While an argument could be made that the failure is useful, most of theany
cases are from remote data which cannot be typed at compile time. In those cases its usually better to assume you might be out of sync with the source, and just provide defaults. In the cases where the source doesn't provide something that is definitely required, then it's best to check for just that condition, rather than validating the entire structure of a response.Error handling is also a good example. In fact, this would make
any
typed catch blocks safe to use in most cases.In the try/catch case, I explicitly typed
err
asany
, which is (currently) considered not to be a good practice. However, I've seen many cases (like error handling) where anunknown
is cast toany
temporarily, specifically so that optional chaining can be used.💻 Use Cases
Make safer usage required where
any
is currently returned, for example values returned byJSON.parse
.Error handling is currently fairly verbose for simple cases.
It could/should be this easy, while still being safe.
The text was updated successfully, but these errors were encountered: