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, 7/23/2024 #59406

Open
DanielRosenwasser opened this issue Jul 24, 2024 · 0 comments
Open

Design Meeting Notes, 7/23/2024 #59406

DanielRosenwasser opened this issue Jul 24, 2024 · 0 comments
Labels
Design Notes Notes from our design meetings

Comments

@DanielRosenwasser
Copy link
Member

deferred vs. immediate vs. ...?

#58729

  • PR is about control flow analysis for direct function expression callbacks in function calls.
  • If this was a "greenfield" project, we would have assumed that CFA always occurred.
  • PR attempts to do this but... TypeScript is 12 years old!
    • One way, you can think of this is "for 12 years we haven't done this, so maybe that ought to be the default".
    • The other way is "this is way more correct, and we should have been doing this all along".
  • We could instead flip the script and say every callback needs an immediate callback.
    • Then we can possibly infer that a callback is immediate.
      • Kind of interesting, but you now need to analyze every usage of a parameter (and the callbacks it is passed to) to determine if it is immediate or deferred.
        • It's very hard (impossible?) to determine if a callback deferred in an automated way.
        • It might not be easy to determine if a callback is immediate either.
          • Need a much more sophisticated analysis due to aliasing and things like that.
  • Might be arguable about immediate vs. deferred - might be a point in time thing in JavaScript.
  • Annotating in general is all very hard to do - libraries aren't great.
  • One perspective: don't like the idea of "inferring" immediate. Parameters generally don't change in our system based on their usage.
  • Also: the analysis is more correct - spiritually agree with doing the analysis. Does it catch bugs?
    • Well people report it on GitHub.
    • They do, but there's a broader audience that probably doesn't report it.
  • For the people who were doing annotating, lots of properties were deferred, but there's no way to annotated options bag properties.
    • Not a problem because those functions don't get annotated - it's just weird.
  • One point in favor of immediate (possibly-invoked) is that we might have a path towards alwaysImmediate or something where you know something is invoked at least once.
    • Also, no need for a strictness flag.
  • What uses alwaysImmediate?
    • new Promise?
    • What if you have 3 callbacks? Right now the PR assumes callbacks are possibly invoked in order, but definite invocation isn't.
  • If we have a lot of discomfort on the feature (requiring deferred) then we should probably not do it - even under a flag.
  • The whole analysis is defeatable with aliasing - so going with immediate is less correct, but it's not that much less correct?
  • Another nicety: going with immediate is that the perf hit is opt-in. If you're annotating, you're probably okay with the perf hit.
    • Means we could also be more aggressive with the analysis!
  • With immediate, afraid of weird community best-practices.
    • "Oh, I hate TypeScript."
    • "Why?"
    • "I always have to write immediate."
    • "What? Are you using a bad lint rule?"
    • "Uh, I dunno, maybe?"
  • Lots of bad lint rules, in practice not a huge issue.
  • Let's go try out immediate. Let's not cram it in for 5.6.

--enforceReadonly

#59326

  • Need to update the DOM generator - currently overriding the generated code.
  • Do we want this to be --strictReadonly?
  • In 10 years, do we think people would use this flag?
    • Might not use it ourselves, even if under "strict": true
  • Means we can't call it --strictReadonly.
    • Not necessarily true.
  • Kind of feels like we chicken out a lot on adding new options to --strict.
  • Let's wait until 5.7 to make sure DefinitelyTyped and DOM and lib.d.ts are ready. Feels like a rush.

Checking Computed Properties/Symbol Keyed Properties for override

#57146

  • We introduced a change where noImplicitOverride now (correctly) introduces errors on computed properties.
  • Drizzle got hit really hard with this.
  • So as an FYI, projects migth get hundreds of errors.
    • Hundreds?
    • Yes, because of built-in symbols, special built-ins, etc.
  • It's a little funny - with symbol keys, the "I misspelled the method" issue is way way way less common anyway. But you'll still find out about base classes removing members which is nice.
  • There's a quick fix, and this is a non-strict opt-in flag. You probably want the error.
@RyanCavanaugh RyanCavanaugh added the Design Notes Notes from our design meetings label Jul 26, 2024
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

2 participants