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, 9/15/2017 #18513

Closed
DanielRosenwasser opened this issue Sep 15, 2017 · 1 comment
Closed

Design Meeting Notes, 9/15/2017 #18513

DanielRosenwasser opened this issue Sep 15, 2017 · 1 comment
Labels
Design Notes Notes from our design meetings

Comments

@DanielRosenwasser
Copy link
Member

DanielRosenwasser commented Sep 15, 2017

Error Suppression

#18457

  • ts-check has allowed error suppression with // @ts-ignore comments.
  • We've not wanted to add this because in most cases, people have just needed simple fixes.
  • More motivating case: in large codebases, parts are unmaintained but broken.
    • Code still works, but doesn't type-check, but who will
  • Do we want to allow descriptive text after ts-ignore?
    • Maybe don't allow the colon.
  • Conclusion: Just allow the colon, let's do it.

Variance

  • Have thought about a --strictFunctionTypes mode, and have an experimental implementation.
    • Under this flag, when relating "function types" (but not methods!), parameters are related contravariantly.
    • Does a "function type" include an object type with call signatures?
      • Yes.
    • Currently placed under the --strict family of compiler options.
    • It's not 100% of the way, but it gets you much closer.
    • Under this mode
  • New subtlety - right now when we relate between type references, we relate their type parameters covariantly because parameter types will be related covariantly.
    • But we can no longer make this assumption.
    • To do a simple check, just fathom up a type and a known subtype, perform instantiation of the types, and relate them.
      • What about many type parameters?
        • Keep the arguments the same, flip each of them to test each type parameter's variance.
      • What about constraints on type parameters?
        • We might need to think more deeply about it.
  • Tried it on the compiler and real world code, and found mostly good errors.
  • Also to examine: when doing type arg inference, we need to find the best common subtype, not the best common supertype.
    • Will we produce an intersection?
    • No, we'll try to still choose a type from the set of candidate types inferred.
  • May need to revisit rules for overload/implementation relation checking?

Mapped types to allow numeric constraint types

#18346

  • We moved number outside of the keyof type.
    • Broke people, people wanted it again.
  • With this change, you can now have enums, and numeric literals, and number in the position of the iterated type in a mapped type.
  • Why not give it a string-indexer instead?
    • Because then you allow non-numeric keys of any name.
  • But this going to be odd, everything about mapped types we've implemented has the assumption of string-like keys.
    • What about a tokey type operator? That might make relations easier to reason about.
  • Many different things just won't work here unless you have some way to encode and/or recognize number-like keys.
    • strumber?
    • numster?
      • Is that your new startup name?
  • Conclusion: continue investigating.

Nominal types

  • What do people want here?
    • Verified data
    • Units of measure
    • Opaque types
    • Nominal classes...?
      • Are we sure?
      • Well, people definitely want instanceof to work correctly.
  • Out of time.
@DanielRosenwasser DanielRosenwasser added the Design Notes Notes from our design meetings label Sep 15, 2017
@RyanCavanaugh
Copy link
Member

Nominal types see #202

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

No branches or pull requests

2 participants