You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
The text was updated successfully, but these errors were encountered:
deferred
vs.immediate
vs. ...?#58729
immediate
callback.immediate
.immediate
ordeferred
.deferred
in an automated way.immediate
either.immediate
. Parameters generally don't change in our system based on their usage.deferred
, but there's no way to annotated options bag properties.immediate
(possibly-invoked) is that we might have a path towardsalwaysImmediate
or something where you know something is invoked at least once.alwaysImmediate
?new Promise
?deferred
) then we should probably not do it - even under a flag.immediate
is less correct, but it's not that much less correct?immediate
is that the perf hit is opt-in. If you're annotating, you're probably okay with the perf hit.immediate
, afraid of weird community best-practices.immediate
."immediate
. Let's not cram it in for 5.6.--enforceReadonly
#59326
--strictReadonly
?"strict": true
--strictReadonly
.--strict
.Checking Computed Properties/Symbol Keyed Properties for
override
#57146
noImplicitOverride
now (correctly) introduces errors on computed properties.The text was updated successfully, but these errors were encountered: