Repository: TypeScript
Issue: Design Meeting Notes, 7/23/2024
Labels: Design Notes

# `deferred` vs. `immediate` vs. ...?

https://github.com/microsoft/TypeScript/pull/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`

https://github.com/microsoft/TypeScript/pull/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`

https://github.com/microsoft/TypeScript/pull/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.