Closed
Description
Variant Accessors
- Can have a getter that returns a
string
, setter that takes astring | 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 onT
.
- 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
- Very popular feature request.
class Base {
foo() {}
bar() {}
}
class Derived {
foo() {}
bar() {}
}
- Want to know about when
foo
orbar
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
- 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.
- Template literal types for contextually typed template literal expressions #43376
- Signals intent of how you mean to use the template string.
- Technically a break, but could infer a template type and have that inferred by a type parameter.
- 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. 😄