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
import type only imported the type side of things! (as well as the namespace space)
Now, import type imports the value meaning - it imports everything - but we'll report an error on anything whose usage would
Seems like import type is a misnomer.
Doesn't just import types!
We also do typeof import(...).SomeStuff which is a special type of way to reference types.
What does Flow do?
Does what import type originally does (only imports types), but the issue was marked as resolved and closed.
Flow has import typeof separately.
What about the fact that import type will now shadow values?
importtype{Promise}from"bluebird";
Should have a test case for weird type-directed emit corner case.
Needs to issue an error, and mark an import as used for values.
Seems like the PR adds some overhead.
3%!?
Why? Well, whenever you reference an alias, we need to determine whether a module is transitively marked as import/export type to know whether an import is used in value position.
// ./foo.tsletFoo=100;exporttype{Foo};// ./bar.tsimport{Foo}from"./foo.js";// Need to error here, but this requires deeper resolution.Foo;
Had a suggestion that anything that's exporting using export type can only be imported using import type.
Unclear if this is really the bottleneck - maybe several walks.
Implementation stuff
Could use a SymbolFlags and "don't do anything unless SymbolFlags is an alias.
Clear that we need to fix the performance issue.
Conclusion: direction seems good, just need to make sure it's fast.
Observing different behaviors between errors reported on concrete types vs. conditional types.
We measure conditional types as invariant in the extends position (the right side of the extends).
We really don't know at the higher-order what they might do.
The "right" thing to do is to mark them as unmeasurable.
Making things "unmeasurable" means you need to do deep comparisons.
If you did that, and had a type Foo<T>, and T is used in the extends position (the right side of the extends), then every instantiation of Foo needs to be compared structurally.
This means something could cause performance issues.
Unmeasurable is more accurate, but slower.
Invariant is less complete, but is faster.
Will this matter?
People started hitting similar issues with mapped types, and we fixed it by adding unmeasurable variance markers.
There is a long-running PR open to fix this (#31277) which is blocked by the lack of type relationships necessary to support structural checking for conditional types. Perf could be an issue, but as it stands, I think the main concern is the breaks it will introduce without additional changes.
import type
Changes#36092
typeof
type queries onimport type
.import type
only imported the type side of things! (as well as the namespace space)import type
imports the value meaning - it imports everything - but we'll report an error on anything whose usage wouldimport type
is a misnomer.typeof import(...).SomeStuff
which is a special type of way to reference types.import type
originally does (only imports types), but the issue was marked as resolved and closed.import typeof
separately.import type
will now shadow values?3%!?
Why? Well, whenever you reference an alias, we need to determine whether a module is transitively marked as
import
/export type
to know whether animport
is used in value position.Had a suggestion that anything that's exporting using
export type
can only be imported usingimport type
.Unclear if this is really the bottleneck - maybe several walks.
SymbolFlags
and "don't do anything unlessSymbolFlags
is an alias.Optional Chaining with Non-Null Assertions
#36031
a?.b!.c
currently means(a?.b!).c
which breaks the optional chain.!
is allowed as part of a chain, and is fully erased toa?.b.c
.!
in a chain.(a?.b as Foo).c
.Variance Measurements
#32674
#32608
extends
position (the right side of theextends
).type Foo<T>
, andT
is used in theextends
position (the right side of theextends
), then every instantiation ofFoo
needs to be compared structurally.The
promised T
Type#35998
Why is this needed?
awaited T
was a thing,foo
would returnawaited T
, and when instantiated, would result inPromise<number>
.We started out talking about this in Adds 'awaited' type to better handle promise resolution and await #17077, but we said that it would be bad to special-case this behavior.
Promise
sPromise
assimilation.There's now a bunch of PRs that try to model
Promise.all
,Promise.any
, andPromise.allSettled
.But this is a whole new other kind of type.
What's the problem with
Promise.all
?Is this a breaking change?
async function
that returns the element access of a generic type, and we used to return the element type - now it'sawaited T[K]
.Why is this urgent?
Conclusion: need to assess community impact - RWC and DefinitelyTyped.
The text was updated successfully, but these errors were encountered: