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/31/2021 #43582

Closed
DanielRosenwasser opened this issue Apr 7, 2021 · 1 comment
Closed

Design Meeting Notes, 3/31/2021 #43582

DanielRosenwasser opened this issue Apr 7, 2021 · 1 comment
Labels
Design Notes Notes from our design meetings

Comments

@DanielRosenwasser
Copy link
Member

Tracking Substitution Type Replacement

#43427
#43425
#43439

  • We create "substitution types" in conditional types - when writing T extends U ? TrueBranch : FalseBranch, we substitute T with something that's sort of equivalent to T & U in the TrueBranch.
  • Doing a "dumb" substitution.
  • When did we start supporting substitution types on primitives/literals?
    • Turns out it's relied upon quite a bit!

    • If you write "foo" extends keyof T ? ... : ..., you want to make a substitution type of "foo" and keyof T so that you can index into T with it in the true branch!

    • Example:

      // Ensure the following real-world example that relies on substitution still works
      type ExtractParameters<T> = "parameters" extends keyof T
      // The above allows "parameters" to index `T` since all later
      // instances are actually implicitly `"parameters" & keyof T`
          ? {​​
              [K in keyof T["parameters"]]: T["parameters"][K];
          }​​[keyof T["parameters"]]
          : {​​}​​;
  • You can figure that in contravariant positions, you don't actually want to produce the substitution type.
    • The issue is that not every use of a type implies strict variance. You could end up with some invariant and covariant and contravariant uses.
  • Should you create unions in contravariant positions?
    • Hard to reason about - leave it alone for now.
  • PR seems right, get some more eyes on it.

Fixing Excessive Stack Depth Issues

#43249

Performance Depends on Declaration Order

#43437

  • If you have a const that uses an interface before it's declared...it's somehow slower!
  • The spread is also suspicious - spreads can create huge anonymous types.
  • Potentially related to lower type IDs.
    • Subtype reduction picks the one with a lower type ID, but that could be worse to compare against.
    • Also, might just not be hitting the relationship cache.
  • Investigation: start at high number, go down.
    • It didn't work. 😱
  • Unclear what to do about it though.

Decorators Metadata Compat for SES

#43463

@DanielRosenwasser DanielRosenwasser added the Design Notes Notes from our design meetings label Apr 7, 2021
@awerlogus
Copy link

@DanielRosenwasser

Unclear if there's a potential better way to write FlatArray. Will experiment

It's possible to write log2(n) algorithm instead of the linear one after #43591 is fixed

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