Skip to content
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

Design Meeting Notes, 3/4/2022 #48208

Closed
DanielRosenwasser opened this issue Mar 10, 2022 · 1 comment
Closed

Design Meeting Notes, 3/4/2022 #48208

DanielRosenwasser opened this issue Mar 10, 2022 · 1 comment
Labels
Design Notes Notes from our design meetings

Comments

@DanielRosenwasser
Copy link
Member

extends Constraints on infer Type Parameters

#48112

  • Was using a separate type alias to constrain an infer type parameter.

  • Required little to no changes; scope felt small.

  • Means you can avoid levels of cascading.

    // before
    type Pair =
        T extends [infer U] ?
            U extends string ? ["string", U] :
            U extends number ? ["number", U] :
            never :
        never;
    
    // after
    type Pair =
        T extends [infer U extends string] ? ["string", U] :
        T extends [infer U extends number] ? ["number", U] :
        never;
  • Could achieve some of this with a type alias

    type Is<T extends U, U> = T;
  • What about a [infer T, infer U extends T]?

    • It's not that inference fails, it's that maybe the constraint would be violated?
  • Need to think through whether there's weirdness here.

  • In theory shouldn't have any weirdness compared to regular type parameters.

  • Right now the infer parameters are not in scope with respect to each other.

    • So that means that they can't go circular w.r.t. each other?
    • Ideally yes. Makes us feel better about this.
  • Parsing issues that could break existing code?

    type X<T> = T extends { x: infer P extends U ? 1 : 0 } ? 1 : 0;
    //                         ^^^^^^^^^^^^^^^^^
    // now looks like an `infer` type with a constraint
    • infer in the checked type? wtf does this mean?
    • Practically nothing except when you're inferred from another conditional type.
    • 😫
      Could say "you need to parenthesize infer P"
  • So there's at least an ambiguity. Could get away with some speculative parsing to disambiguate.

  • Another test case: make sure that an outer type parameter used in a constraint works.

infer Improvements in Template Literal Types

#48094

  • Idea: constrained types with a round-trippable string representation can be inferred for infers in template strings when you enforce a constraint with something like type Is<T extends U, U> = T (or the constraint feature mentioned above).
  • If you can get away with Is<T extends U, U> = T, do we really need to add syntax?
    • Well we don't feel good about people having to learn this.
    • Also, you can avoid those nested conditional checks.
@DanielRosenwasser DanielRosenwasser added the Design Notes Notes from our design meetings label Mar 10, 2022
@harrysolovay
Copy link

This will be a MASSIVE improvement. I wanted to drop this link to a tangentially-related issue from a while back. Thank you for all of your work!

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