Open
Description
deferred
vs. immediate
vs. ...?
- 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
ordeferred
.- 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.
- It's very hard (impossible?) to determine if a callback
- 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
- Then we can possibly infer that a callback is
- 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 towardsalwaysImmediate
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
- 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
- Might not use it ourselves, even if under
- 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
- 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.