Skip to content

Design Meeting Notes, 9/27/2019 #34573

Closed
Closed
@DanielRosenwasser

Description

@DanielRosenwasser

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

Activity

IllusionMH

IllusionMH commented on Oct 25, 2019

@IllusionMH
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

Metadata

Metadata

Assignees

No one assigned

    Labels

    Design NotesNotes from our design meetings

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

      Development

      No branches or pull requests

        Participants

        @DanielRosenwasser@IllusionMH

        Issue actions

          Design Meeting Notes, 9/27/2019 · Issue #34573 · microsoft/TypeScript