You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Request: positive and negative numbers as a subtype of number #41666
Unlike the proposals requesting explicitly sized values, such as i32, I am requesting a type that differentiates between negative numbers and positive numbers.
Use Cases
This has immediate use practically everywhere.
There are a whole lot of times where numbers are intended to be positive numbers.
For example, indexing arrays should always be positive:
typeArray<T>={[key: positive_number]: T};
Why the hell would you want a negative index!?
Furthermore, plenty of built-in functions just throw errors for using negatives.
If anything, they can prevent using negative constants in places where there should be positives.
Granted, there are plenty of places where generic number stills fits just fine. Also, I have no clue what we do about NaN.
And lastly, it is unlikely that negative literals are ever used erroneously, but negative runtime values can make it into places where... you wouldn't want them to be.
Examples
Introduce a way to denote that a number or bigint should be positive or negative.
letx: positiveNumber=3;// fine, constant 3 is positive
...
x=-5;// error, constant "-5" is not a subtype of positiveNumberx=24654.36546;// not negative, perfectly finex=-7asunknownaspositiveNumber;// hands off, that's on the developerx=Infinity;// questionable, but still positivex=-0;// ???x=NaN;// ???
Checklist
My suggestion meets these guidelines:
[ x ] This wouldn't be a breaking change in existing TypeScript/JavaScript code
[ x ] This wouldn't change the runtime behavior of existing JavaScript code
[ x ] This could be implemented without emitting different JS based on the types of the expressions
[ x ] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
For the same reasons that it's impractical to support an int type, I think it's impractical to support a negative type and a positive type. You'd need deeper data flow analysis to determine whether arithmetic on any two values will always continue to be a positive number, and any case where you don't is so trivial that a feature like this is probably not useful.
As another nit: the Array case is especially not a great motivation because TypeScript specifically wouldn't be able to catch that without introducing unrelated breaking changes. If you swapped the arrayLength parameter to be of type positive_number, it would just fall to the next overload. If you fix the ...items overload to type [T, T, ...T[]], then you're breaking other code.
That request asked for type emits for runtime performance, this does not.
Performance was just a side-note and the type emit an optional suggestion. The major point was to represent a subset of number to catch errors early on, the same as your issue.
I would just say most operations should yield a number.
I'd be looking forward to the frequent issues of "Why is positive 1 + positive 3 a number, and not a positive number?"
Activity
DanielRosenwasser commentedon Nov 24, 2020
For the same reasons that it's impractical to support an int type, I think it's impractical to support a negative type and a positive type. You'd need deeper data flow analysis to determine whether arithmetic on any two values will always continue to be a positive number, and any case where you don't is so trivial that a feature like this is probably not useful.
As another nit: the
Arraycase is especially not a great motivation because TypeScript specifically wouldn't be able to catch that without introducing unrelated breaking changes. If you swapped thearrayLengthparameter to be of typepositive_number, it would just fall to the next overload. If you fix the...itemsoverload to type[T, T, ...T[]], then you're breaking other code.MartinJohns commentedon Nov 25, 2020
Performance was just a side-note and the type emit an optional suggestion. The major point was to represent a subset of
numberto catch errors early on, the same as your issue.I'd be looking forward to the frequent issues of "Why is positive 1 + positive 3 a number, and not a positive number?"