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
by getting the type of both branches and unioning them - and we can't make a determination about how either branch corresponds to the condition.
In the experimental PR, each branch is checked the expected type.
This is a breaking change, but it catches some desirable breaks.
For example:
// Currently the expression's type is `any` and we check that against `number`,
// but checked individually, the `string` is correctly caught.
let x: number = arg === 1 ? "someString" : getAnAny() as any;
Breaks?
Most are true bugs
Good chunk are moves in error positions (breaks ts-expect-error)
Some unlikely to be real bugs.
The motivation was conditional type narrowing - if you think of first principals, you could consider that the conditional expression creates a conditional type.
Not too hard to do, but
Need to be able to "crack into" each branch of the conditional type for the return statement case as well.
You also might not get the "right" conditional type. For example
function f(x: T): T extends string ? string : number {
return x === undefined ? someString : someNumber;
}
Do you end up synthesizing T extends string ? ... : ... or do you create T extends undefined ? ... : ...?
Also, error messages won't be quite as good.
Out of time
Slim AST Experiments with Shared Structs in the Compiler
If you use shared structs as the backing store for the slim AST, you lose some speed (we anticipate more optimizations with collaboration from V8), but possibly win back some memory and are able to run across multiple threads and you get a net perf win.
Node Type
Allocation Source
Time (seconds)
Current AST
Plain objects
1.76
slim-ast
plain objects
1.562
slim-ast
shared structs
2.013
slim-ast
shared structs across 8 workers
1.082
The text was updated successfully, but these errors were encountered:
Clarification about conditional expression checking: the change in my PR is only for conditional expressions in a return statement, so this will remain the same:
letx: number=arg===1 ? "someString" : getAnAny()asany;// no error
This will now error:
functionfun(arg: number): number{returnarg===1 ? "someString" : getAnAny()asany;// error in PR}
Conditional Type Narrowing
#56941
Today, we check an expression like
by getting the type of both branches and unioning them - and we can't make a determination about how either branch corresponds to the condition.
In the experimental PR, each branch is checked the expected type.
This is a breaking change, but it catches some desirable breaks.
For example:
Breaks?
ts-expect-error
)The motivation was conditional type narrowing - if you think of first principals, you could consider that the conditional expression creates a conditional type.
Need to be able to "crack into" each branch of the conditional type for the
return
statement case as well.You also might not get the "right" conditional type. For example
T extends string ? ... : ...
or do you createT extends undefined ? ... : ...
?Also, error messages won't be quite as good.
Out of time
Slim AST Experiments with Shared Structs in the Compiler
#59992
Partially inspired by Make AST nodes monomorphic. #59190
Uses flagged functionality for
SharedStruct
s via API (no syntax for shared structs yet).Idea: every Node is has single a fixed layout.
Separately: a different experiment Uses a "slim AST" which creates a facade to the real AST for API compat.
Experimental parser that uses this.
You get a speed-up similar to Make AST nodes monomorphic. #59190, though it's at the expense of more memory.
If you use shared structs as the backing store for the slim AST, you lose some speed (we anticipate more optimizations with collaboration from V8), but possibly win back some memory and are able to run across multiple threads and you get a net perf win.
The text was updated successfully, but these errors were encountered: