Repository navigation
Literal type initialization with inheritance #10484
Description
Activity
We tried this a while back, but failed to find a good solution. #6118 gives the result of that work.
Proposals are welcome to fix this problem.
Nathan Shively-Sanders (@sandersn) I read your comment about RWC. It seems the main issue is lack of variance contract for members of classes. Typing a property with a narrower type in a derived class is OK if your code only reads from the base class but possibly broken if you also write. And there is no way to know this.
In a greenfield there are easy way to fix this, but of course they break existing code 👎 .
Given the constraints, I don't see a good easy solution to make it work + make it backward compatible.Only thing that comes to mind is a compiler flag 😦
The benefits are important though. Here are some annoyances that I encounter on a daily basis:- The example above, where assigning a string to a literal type fails.
- Typing empty arrays! In a derived class or interface or literal parameter,
xs = []fails and is annoying as hell. - Implicitly typed lambda parameters!
- Bugs because overrides are not properly checked at all.
Some of those are so frequent that I would love even a partial fix, e.g. the empty array initializer and implicitely typed lambdas. Those should be doable with backward compatibility, I think?
At this point we're starting to consider patchwork fixes instead of a general fix. Daniel Rosenwasser (@DanielRosenwasser) and I were going to get together soon to brainstorm some way to make partial fixes easy to explain if not completely consistent.
In order of likelihood, this is what I'm thinking we would be able to solve:
- Overrides without type annotations — otherwise you don't invoke contextual typing. (Modifying contextual typing to work with partial annotations is another big, separate problem complicated primarily by the interaction of contextual typing of lambdas while doing type parameter inference).
- Empty arrays assigned to an overridden property.
- Un-annotated lambdas assigned to an overridden property. This one seems like the same thing as overridden methods, but they are treated differently by the compiler in some ways.
- Typing string literals/null/undefined. There is a long tail of problems that are harder to solve and also have less value. (a property
p = nullgives youp: anywhich degrades checking but is otherwise benign).
Unfortunately, the deeper you go on the list, the more of a random bag of patches it becomes. I'm not sure of a solution for that either.
Nathan Shively-Sanders (@sandersn) It is a good list!
I think all my main offenders are on it, thanks! 👏- locked and limited conversation to collaborators
on Jun 19, 2018
TypeScript Version: nightly (2.1.0-dev.20160822)
Code
Expected behavior: Should compile without error. Code seems intuitive to me.
Actual behavior: error TS2415: Class 'B' incorrectly extends base class. Type 'string' is not assignable to type '"a" | "b"'.