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/26/2021 #43581

Closed
DanielRosenwasser opened this issue Apr 7, 2021 · 0 comments
Closed

Design Meeting Notes, 3/26/2021 #43581

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

Comments

@DanielRosenwasser
Copy link
Member

Variant Accessors

#42425

  • Can have a getter that returns a string, setter that takes a string | number.
  • Pretty common, comes up in the DOM.
  • Note: implementation bug allowed a body in the signature of a type.
  • The getter and setter types must be related.
  • The getter type must be more derived than setter.
  • Mix in accessibility (e.g. protected get, private set)
  • Only activates on assignments.
    • Elsewhere in the type system, the setter is ignored, and the read type is referenced.
    • For example, a mapped type over a keyof T will map on the getter types of properties on T.
  • Not doing the "more invasive" change.
    • Would have to account for separate reads and writes in every code path.
    • May not be feasible.
  • Doing assignment-check means someone will come to us after this feature goes in, say "my mapped type doesn't work with write types".
    • Would have to be able to talk about read/write types in the mapped type.
  • Seems like we can do
  • Make sure .d.ts emit is good.
  • Make sure Babel, ESLint, downlevel-dts are supported before stable.
  • Try to get it in by end-of-day with review.

noImplicitOverride

#39669

  • Very popular feature request.
class Base {
    foo() {}
    bar() {}
}

class Derived {
    foo() {}
    bar() {}
}
  • Want to know about when foo or bar gets renamed and issue an error.
  • That's the point of the override keyword.
class Derived {
    override foo() {}
    override bar() {}
}
  • What about the "opposite" - when you want to avoid "accidentally" overriding a method?
    • Can't just error.
    • noImplicitOverride
class Derived2 {
    foo() {}
    bar() {}
}

Inference and Relatability Between Template Literal Types

#43376
#43361

  • Did work to intentionally preserve template types in 4.2.
    • Tried to address an asymmetry between strings and template strings.
  • Had to back it out, affected too much.
  • But we also backed out a lot of useful functionality.
  • Made a few changes.
  • First, if you are contextually typed by a template literal or string literal type, you probably want the template literal type.
  • Now are able to better-infer between template strings, and relate between them based on string contents, even if they don't have the same template literal contents.
  • Had a change where inferred 2 consecutive placeholders (type variables), we would infer one character.
    • What happens if you infer from a "template hole"?
    • Well we just infer that template hole.
    • Kind of weird, but it's the best you can do.
  • This now affects subtype type reduction too.
    • We want to assume that this better subtype reduction is better. 😄
@DanielRosenwasser DanielRosenwasser added the Design Notes Notes from our design meetings label Apr 7, 2021
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