Skip to content

Design Meeting Notes, 9/27/2019 #34573

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
DanielRosenwasser opened this issue Oct 18, 2019 · 1 comment
Closed

Design Meeting Notes, 9/27/2019 #34573

DanielRosenwasser opened this issue Oct 18, 2019 · 1 comment
Labels
Design Notes Notes from our design meetings

Comments

@DanielRosenwasser
Copy link
Member

Errors for Certain Asssertions and Never-Returning Functions

#33622

  • We now need to do control flow analysis for statement-expression level calls.

  • But resolving the expression that's being called (i.e. f in f(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

  • 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

#30593

  • 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

#32064

  • Non-controversial.
  • Does this allow template literals for string literal types?
    • Not currently.
  • Ship it!

ts-nocheck in TS files

#33383

  • 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
@DanielRosenwasser DanielRosenwasser added the Design Notes Notes from our design meetings label Oct 18, 2019
@IllusionMH
Copy link
Contributor

  • Does this allow template literals for string literal types?
    • Not currently.

If you mean NoSubstitutionTemplateLiterals they works since TS 2.7 at least.
No changes to template literals with expressions though.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Design Notes Notes from our design meetings
Projects
None yet
Development

No branches or pull requests

2 participants