int32 type returned by bitwise operators

Search Terms

bitwise operators, integer type, int32

Suggestion

Add an int32 subtype for number returned by TypeScript from bitwise operators.

function coerce(n: number): int32 {
  return n | 0;
}

JavaScript bitwise operators coerce arguments to int32 and the return type of those operators will always be an int32.

This would not be a breaking change since int32 would be a subtype of number. Only bitwise operations would change to return int32s.

EDIT: I now recommend calling the type BitwiseInt32 so that user’s won’t see the type as a generic integer type.

Use Cases

Helps applications which are trying to take advantage of JavaScript implementations int32 optimizations. An application could ask for an int32 parameter to force coercion with n | 0.

Checklist

My suggestion meets these guidelines:

• This wouldn’t be a breaking change in existing TypeScript/JavaScript code
• This wouldn’t change the runtime behavior of existing JavaScript code
• This could be implemented without emitting different JS based on the types of the expressions
• This isn’t a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
• This feature would agree with the rest of TypeScript’s Design Goals.

[nmain]

What about a uint32 type for >>> 0?

[make-github-pseudonymous-again]

I would like #195. I want to use int32 for performance reasons: I have one use case where numbers up to 2**31-1 is enough (array indexes, I know these can go up to Number.MAX_SAFE_INTEGER but I do not care about handling numbers that large), and where coercing parameters and the output of every arithmetic operation by adding | 0 (for instance, ++i ~ (i = i+1|0)) yields significant time saving and produces compiled code almost twice smaller even though more subroutine calls are inlined (10KB instead of 17KB, I used Indicium to witness that).

I think what I have experienced can be extrapolated. I have the feeling that this addition would make basic algorithms in JavaScript much less resource consuming (if you agree to limit yourself to inputs of reasonable size). This claim would need to be evaluated.

I agree this example use case is a niche. I do not want int32 to be the new number. Even more so if it means errors due to implicit integer division or integer overflow.

Indeed a workaround is to have a branded int32 type, a coercion function, and arithmetic functions. But I have sufficiently many arithmetic operations in my code that I fancy leaving the responsibility to TypeScript would not be a luxury. I am probably wrong. Maybe all we need is a tiny library which includes said type and functions.

Nervetheless, if this responsibility would be shifted to TypeScript, I can see two problems in code emission:

• It’s not just about dropping types anymore, you need to emit transformed code (maybe this then falls out of scope of TypeScript).
• What do you do with inferred types? Do you require explicit types for the transform to kick in?

PS: If going the workaround route then explicit inlining hints would be relevant (see https://github.com/microsoft/TypeScript/issues/661 for instance). The current v8 is excellent at inlining what needs to be inlined, I do not deny it, I have seen it in action and it is impressive. That does not contradict wanting more control on code emission. The better argument would be that implementing this takes time both for conception and maintenance, and has limited applicability. If we want to argue code size, replacing a(x,y) by x+y|0 uses one less character but a(a(x,y),z) would need parentheses (x+y|0)+z|0 and now we are equal, inlining a(a(a(x,y),z),w) emits something with one more character. Not sure if output size is relevant. The case (i = i+1|0) would be better served by a macro or a code transform as you cannot wrap the assignment in a function call but if we cannot have that then (i = f(i)) already saves one character because the right operand is constant. Hence we cannot argue inlining will always save bytes, nor can we argue it will always use more. A reasonable argument against implementing inlining hints in TypeScript is that minifiers can do that job, giving even more control (although, at the moment, terser produces an IIFE for some (each?) inlined call, and there is no way to guide the process).