Skip to content

Design Meeting Notes, 2/16/2018 #22011

Closed
Closed
@DanielRosenwasser

Description

@DanielRosenwasser

Recursive Conditional Types

#21316 (comment)

  • @tycho01 already reiterated we have recursive conditional types with indexed access types on object types (Add Awaited<T> to core library #21613 (comment))
    • Well damn it, if you can already do it with object types, why make it ugly to do with regular conditional types?
  • Conditional types contain 4 types
    • The checked type, the extends type, the true type, and the false type
    • When the condition is definitely true or false, we do an immediate instantiation (/evaluation) of the respective branch
    • Those branches are already sort of deferral points, much like the object member types.
    • If an conditional type is instantiated over 100 times, we consider that to be too deep.
      • At that point, we try to find the respective alias type that contains that conditional type.
  • [[Demonstration of Peano-style arithmetic with multiplication]]
  • Challenges
    1. The "we've instantiated too deeply" error is issued on the declaration instead of the usage, which is not totally obvious.
    2. The act of checking whether a type satisfies a constraint in a conditional type (e.g. seeing if A is assignable to B in A extends B) requires evaluating A.
      • That means if A is a conditional type, either branch needs to be evaluated immediately to see if it satisfies B. That means you can end up exhausting your instantiation stack.
  • Question: Why not defer the type when comparing a conditional to the constraint type.
    • doesn't make sense, you need to check now
      • you could imagine that our compiler architecture was more deferred, but that would make it much harder to reason about.
  • Question: or, when you hit the limit, stop evaluating once you hit the limit and defer the evaluation?
  • Also, this instantiation stack limit is quite annoying: you can get errors on unrelated type aliases.
    • What if your stack is tied per type instantiation?
    • Or rather than per type, you use the global stack but check specific types in that stack.
  • Conclusion: give users an error in these situations, try to improve the message.

Ignore specific errors with @ts-ignore comments

Issue: #19139
PR: #21602

  • Given the error code, what are you actually suppressing?
    • Seems entirely unclear.
    • Error codes don't tell you what you're doing
      • Short-names are better than numbers.
  • So short names?
    • But this gives a bad UX; way more on the screen than you wanted.
    • Also, people are probably relying on the error codes even though they shouldn't be!!
    • What if we gave short codes in --pretty?
  • Could give quick info for the error code.
    • Great but how does that help you on a code review on GitHub?
      • Why, do you inherently distrust the code you're reviewing?
        • Sometimes yes?
  • A lot of these are to suppress lint rules.
    • Maybe the solution is just to get out of the linting business. :)
  • What if these comments caused errors when no error's present on the next line?
    • We might feel better about that.
      • Half jokingly: Can you suppress those errors?
        • Now the idea has become a half-joke.
  • Conclusion: no conclusion yet.
  • Post-design meeting realization: original motivation was mass suppression for working code.
    • Seems more reasonable with that in mind.

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

    Issue actions