Skip to content

Design Meeting Notes, 10/30/2020 #41342

Closed
@DanielRosenwasser

Description

@DanielRosenwasser

Speed-Sensitive PRs

Definite-Assignability

#39577

  • Use a definitely-assignable relation in Material-UI
  • If it is a correctness fix, and it's only 1%... that's probably not so terrible.
    • Will manifest in codebases where people can't really even understand the types.
  • Definitely-assignable relation will never probe constraints for these.
    • Isn't this just because any is really unknown and never?
    • Maybe dual-behavior of any biting us.
      • The new relationship is about asking whether any given instantiation will break.
  • 4.2-bound if we want.

Cache Complex Union and Intersection Relations

#37910

  • We have never cached the results of relations between unions and intersections.
    • We only cache relations between constituents.
  • Could try caching all unions/intersections.
    • Made things slower in experiments.
    • Does a bunch of expensive caching - bad!
    • When relating Foo | Bar | Baz to Target, have to cache
      • Foo | Bar | Baz to Target
      • Foo to Target
      • Bar to Target
      • Baz to Target
  • Idea: as soon as we have more than 4 targets to check against, we'll cache.
    • Partial reasoning: avoiding undefined | null | T.
  • This change speeds up the compilers-with-unions test case.
  • Aside: any reason why compilers-with-unions was not in the perf suite?
    • Was crashing, should be good now.
    • Azure might be finally stable in perf numbers.
    • Can we get rid of Node 8/10?
    • And add Node 14/15
    • Perf test fast on LTS/perf test slow
  • Aside: maybe linked caches?
  • 4.2-bound!

Arbitrary Index Signatures (now that we have template string types)

#26797

  • Have this old PR.

  • Would be nice to be able to model data- and aria-.

  • We have two "kinds" of types: finite types and infinite types

    • "foo" - finite
    • "foo" | "bar" - finite
    • string - infinite
    • `aria-${string}` - infinite
  • Can imagine that mapped types on

    • finite types desugar to individual properties.
    • infinite types remain as index signatures.
  • The PR's original motivation was symbol types.

  • As a bonus, it handled string literal types and enums.

    • Those would expand out to keys.
  • Want to propose that index signatures are required to have an infinite type.

    • Including pattern-literal types like `aria-${string}`.
  • Mapped types would be the only thing that can represent keys in a higher-order manner.

    • We would not want to get into the business of { [x: T]: Type } where T is generic.
    • Can't make meaningful statements about T in those cases.
  • We want to have a view that a mapped type can have some key type that can be finite and infinite.

    • At 0-order, these types desugar as described above.
  • But we're already "equipped" to handle these.

    • Index signatures are just another structural component of the type. The hard part is actually adding the index signatures.
  • Feels like we're "ripping out the foundation" to go higher-order.

  • We can ship this with 0-order.

    • Shipping PR with forbidden higher-order is more code.
  • You need to be able to reason about constraints.

  • Follow-up

    • Type with multiple index signatures
      • Every index signature that matches, you union when reading
      • Every index signature that matches, you intersect when writing
  • We have another relationship in the PR where number is assignable to string.

    • You could build it other ways technically.
    • Could do it differently before isRelatedTo
    • But isRelatedTo does the nice logic.
  • What about

    interface Foo {
        [x: `aria-${string}`]: string;
        [x: `aria-yadda-${string}`]: boolean;
    }
    • Would be nice if we could provide a nice error message!
    • Need to be able to relate pattern types to pattern types.
    • Could imagine some set of "easier" prefix/postfix.

Partial Type Argument Inference

#26242

Out-of-time

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