Closed
Description
Breaks from Checks Against Unconstrained Generics
function foo<T>(x: T) {
// Now breaks but is technically correct because
// T could be null/undefined.
takeValue(x);
}
foo(100);
function takeValue(obj: {}) {
}
- It is a "bug fix" for
strictNullChecks
technically. - Why did we pull it out of 4.7?
- We did not properly narrow generic values.
- Operating principles are that
strict
opts you into breaks.strictNullChecks
gives you that.- Could add an extra switch under
strict
that could be opted out.
- Could add an extra switch under
- Balance between pain and benefit?
strict
means pain, but are people getting benefits from the change?- Improve intersection reduction and CFA for truthy, equality, and typeof checks #49119 mentions many solved use-cases.
- Mitigations?
- No quick fix.
- Never had the quick fix.
- Related spans in errors?
- Always suggesting
extends object
. - Real examples were never
object
.
- Always suggesting
- No quick fix.
- Aside:
- TypeScript ESLint rules often complain about
{}
- we don't like that.
- TypeScript ESLint rules often complain about
- Conclusion:
- We do feel like the value is provided while authoring code - hard to see the benefits on existing code. Some cases caught by runtime errors.
- Would like to provide a better quick fix and error message.
- Would like to rerun the new-errors reporter.