Repository navigation
Number literal type allows increment #14745
Description
TypeScript Version: 2.2.1 / Playground
Code
var s10: 10 = 10;
s10++;
s10 += 1;
s10 = s10 + 1; // Type 'number' is not assignable to type '10'.Expected behavior:
Compiler errors on all three lines
Actual behavior:
Only errors on the last line.
This looks like a clear bug. A bit more subtle case is a union of literals where increment may or may not lead to the correct type. That subtlety should probably be folded into integer types, and ignored for now. Increments and += on literal type should error.
Activity
DanielRosenwasser commentedon Feb 21, 2018
@indiescripter go for it! Everything you need should be in
checker.tswhere we check against binary and unary expressions.We also need a new error message like
So go ahead and add that into
diagnosticMessages.jsonand runjake generate-diagnostics.weswigham commentedon Feb 22, 2018
FYI,
could be construed as probably valid code. We just don't do any similar analysis right now (and made a design choice not to).
collin5 commentedon Oct 21, 2018
@indiescripter Are you still working on this? Would love to give this a try if otherwise.
collin5 commentedon Oct 21, 2018
Sorry about that. Will be starting on this soon. Thank you!
collin5 commentedon Nov 5, 2018
I've created a Pull request to resolve this #28344
ahejlsberg commentedon Feb 1, 2019
Some thoughts on this issue...
While it doesn't seem unreasonable to disallow increment, decrement, and compound assignment operators on variables of unit types, it also doesn't seem particularly useful. It just isn't meaningful or common to declare mutable variables of unit types (what would be the point?) so we wouldn't be solving a real world problem.
The real scenario is the semantics of applying those operators to variables of literal union types, i.e. unions of unit types. I don't think it is feasible to just error here--after all, it is perfectly fine to increment a value of type
0 | 1 | 2. Rather, in order to do better we would have to support "type math", i.e. reflecting the effects of the built-in operators on sets of possible values. For example, incrementing a value of type0 | 1 | 2should yield a value of type1 | 2 | 3. However, this quickly gets unwieldy when both operands are union types. For example, multiplication of two values of literal union types with n and m possible values would produce a literal union type with n * m possible values.We have previously decided not to do this because the added complexity (conceptual and in implementation) doesn't justify the marginal gains in type checking. I think this decision still holds, so I'm not sure we really want to do anything here.
mihailik commentedon Feb 2, 2019
Better suggestion.
NO MUTATING operators on ANY literal types.
Fine to have mutating operators on unions, those have funky use cases.