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, 11/16/2018 #28581

Closed
DanielRosenwasser opened this issue Nov 16, 2018 · 0 comments
Closed

Design Meeting Notes, 11/16/2018 #28581

DanielRosenwasser opened this issue Nov 16, 2018 · 0 comments
Labels
Design Notes Notes from our design meetings

Comments

@DanielRosenwasser
Copy link
Member

DanielRosenwasser commented Nov 16, 2018

Arbitrary Index Signatures

#26797

  • Today we only support string and number index signatures.

  • We didn't have symbol index signatures (though it used to be allowed in string index signatures)

  • Now we have bigint - but we don't support those either.

  • People asked for index signatures on enums; but instead we said you could have a mapped type over an enum.

    • However, once you learn about index signatures, that's the intuitive thing to use (even if they're technically less-powerful than a mapped type).
  • As far as implementation goes, it is far reaching but it is reasonable.

    • Conceptually, they're quite similar to regular signatures; we just need to enforce a sort of priority.
  • When you index with something x[y], you have to try to apply the type of y against every index signature of x and union it to get the result.

    • As the duality, when writing an assignment x[y] = z, each type is intersected in the assignment.
  • There is some annoying behavior with these index signatures on literal types.

    interface Foo {
        [index: "a" | "b"]: string;
        [index: "c" | "d"]: number;
    }
    
    // Error! But what's the deal!
    class Bar implements Foo {
        a = "a";
        b = "b";
        c = 10;
        d = 20;
    }
    • Bar hasn't declared explicit index signatures.
    • But when you have index signatures over a closed union, people will expect these to be equivalent. Seems bad.
  • What about "enum-yness"

    • Today, a mapped type over enums just flattens down to the numeric values that an enum maps to.

    • But with the current PR, we keep them distinct.

      enum SomeEnum {
          Zero,
          One,
      }
      interface Foo {
          [index: number]: number;
          [index: SomeEnum]: number;
      }
    • Here, we enforce that both of those index signatures are related to each other.

  • This also doesn't perfectly map to index signatures; you can't toggle optionality with ?.

  • If we started TypeScript over today, would we have both mapped types and index signatures?

    • Why have two ways to represent very similar concepts? Could we try to consolidate on mapped types?
  • [[Discussion around syntax and computed property names]]

  • "I think there's a story around index signatures for creating a set of known property names, and mapped types just being a template."

@DanielRosenwasser DanielRosenwasser added the Design Notes Notes from our design meetings label Nov 16, 2018
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

1 participant