Skip to content
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

Design Meeting Notes, 6/10/2022 #49479

Closed
DanielRosenwasser opened this issue Jun 10, 2022 · 4 comments
Closed

Design Meeting Notes, 6/10/2022 #49479

DanielRosenwasser opened this issue Jun 10, 2022 · 4 comments
Labels
Design Notes Notes from our design meetings

Comments

@DanielRosenwasser
Copy link
Member

DanielRosenwasser commented Jun 10, 2022

Breaks from Checks Against Unconstrained Generics

#49461
#49119
#48923
#48366

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.
  • Balance between pain and benefit?
  • Mitigations?
    • No quick fix.
      • Never had the quick fix.
    • Related spans in errors?
      • Always suggesting extends object.
      • Real examples were never object.
  • Aside:
    • TypeScript ESLint rules often complain about {} - we don't like that.
  • 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.
@DanielRosenwasser DanielRosenwasser added the Design Notes Notes from our design meetings label Jun 10, 2022
@DanielRosenwasser
Copy link
Member Author

@chriskrycho you upvoted #48923. We're going to be giving this a second shot in TypeScript 4.8 as a heads up. Please let us know if there's anything you're running into.

@weswigham
Copy link
Member

Quickfix: #49481

@chriskrycho
Copy link

Thanks for the ping, @DanielRosenwasser! The specific case where I hit it was indeed (at least arguably!) a bug fix, albeit a subtle one, so I’m glad to see this going back in. We’re also targeting this specific error for a good test case for automated fixes for TS breaking changes under strict: true in library code with some (currently experimental) code at LinkedIn, so I’ll let the folks working on that know this is going back in and to test against nightlies once it’s back in. (The quick fix should make it too easy, but that’s appreciated!)

@DanielRosenwasser
Copy link
Member Author

@RyanCavanaugh did a great write-up for others on this change over at #49489

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Design Notes Notes from our design meetings
Projects
None yet
Development

No branches or pull requests

4 participants