Closed
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
Type
Projects
Milestone
Relationships
Development
No branches or pull requests
Activity
IllusionMH commentedon Oct 25, 2019
If you mean
NoSubstitutionTemplateLiterals
they works since TS 2.7 at least.No changes to template literals with expressions though.