-
Notifications
You must be signed in to change notification settings - Fork 12.4k
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
raise a type error on attempt to strict-equal-compare a value of string | null to undefined #14764
Comments
Interested in your thoughts here. We special-cased comparisons against // TypeScript callers: Don't give me 'undefined'
function fn(x: string) {
// JS callers: Read the docs please
if (x === undefined) throw new Error('x cannot be undefined');
} I think that part is non-negotiable -- it should be "cheap" to check for those sorts of errors, by some means or another. Checking a function fn(x?: string) {
if (x === null) { x = "some default" } // This is how it works, right?
} One concern I have is that if (another === <string>undefined) { // Error, can't convert undefined to string Perhaps a type assertion from |
i am not questioning #11920 here, this is what i've been through today though, i had: interface Data { value: number | null; }
declare var data: Data;
if (data.value === null) {
// do things
} then i refactored interface Data { value: number | undefined; } and if (data.value === null) {
// do things
} hasn't been caught, bang! a problem so it wasn't a silly comparison by choice, just something vulnerable to refactoring that typescript can't see |
experienced the same problem today: I refactored a |
I really want some strictNullChecks real-world projects so we could test this stuff out |
i have one, willing to test it |
Ironically, I work on a codebase where we're incrementally enabling strictNullChecks and was bit by this. To support strictNullChecks , the following change was made: - let applyMemoryInitializer: () => void;
+ let applyMemoryInitializer: (() => void) | null = null; A later condition was overlooked, and became always-true. if (applyMemoryInitializer !== undefined) {
...
} |
@RyanCavanaugh It's been several years, is more feedback still desired? This something I've been bit by in the past and might have gotten bit by just now, if I didn't recall TypeScript's behavior in this situation. Real simple case. I had some code that explicitly returned |
the following examples are almost certainly bugs:
consider raising a type error for the above situations
The text was updated successfully, but these errors were encountered: