Skip to content

Design Meeting Notes, 7/23/2024 #59406

Open
@DanielRosenwasser

Description

@DanielRosenwasser

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    Design NotesNotes from our design meetings

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions