-
Notifications
You must be signed in to change notification settings - Fork 12.9k
Closed
Labels
Design NotesNotes from our design meetingsNotes from our design meetings
Description
Errors for Certain Asssertions and Never-Returning Functions
-
We now need to do control flow analysis for statement-expression level calls.
-
But resolving the expression that's being called (i.e.
f
inf(x, y, z)
) can kick off more control-flow analysis.- And that can cause a loop in the control flow graph, which we can't make sense of.
-
Instead of erroring on the call, why not call
- [[@weswigham fill this in]]
-
But this also forces you to add an explicit annotation for something like
const tester: Tester = new Tester();
-
The alternative is that we just "let control flow analysis do its thing" but that causes breaks in the compiler itself.
- This also means that we're hitting other issues which don't related
-
These declarations really should never be considered circularity errors but they are.
- But you can't know they're "unrelated" until you resolve them which could cause that circularity!
-
Maybe you kind of want to get the type of something as if control flow had never taken effect?
- Can you even do this?
- Also, would it be confusing to fall back back to a different type only some of the time here?
-
Discuss offline.
-
Do we need more time to figure this out?
- This seems like the minimal viable product that solves most of the use-cases.
-
Alternative PR which breaks existing code is not viable.
-
Resolution
- This is technically a breaking change - document it.
- This is a reasonable start - we can iterate on the implementation later.
- Seed a StackOverflow question because this is confusing.
Narrowing non-declared union types
- Basically the idea is that we only narrow when the type a variable is declared with (the "declared type") determines if we should narrow using discriminated unions.
- What is desired is that once something is narrowed to a discriminatable union type, we should correctly narrow on each discrimination.
- What is the crux of the change?
- Currently tracks only the last union that's been encountered.
- Question is whether or not adding in a stack or "limited-depth buffer" is appropriate.
- Conclusion: Need to actually give feedback on the implementation.
Improved Template String Support in Type-Checking
- Non-controversial.
- Does this allow template literals for string literal types?
- Not currently.
- Ship it!
ts-nocheck in TS files
- We support
ts-ignore
in both JS and TS files. - We support
ts-nocheck
in JS files, but not TS files! - Valuable for migration scenarios.
- Do we offer suggestions to ts-ignore in TypeScript?
- Yes in JS files, no in TS files.
- Does this play well with declaration file emit?
- The same is true of ts-ignore today.
- Conclusion
- 3.7-bound
Metadata
Metadata
Assignees
Labels
Design NotesNotes from our design meetingsNotes from our design meetings