Suggestion: int type

[fdecampredon]

Introducing int type could allows some error to be caught at compile time (like trying to index an array with a float) and perhaps improve performance of outputted javascript, to obtains true int, TypeScript could systematically emit a cas with |0 when a variable/parameter is an integer :

var i: int; 
var n: number;
var a: any = 1.2;
i = 1.1; // error;
i = n; // error
i = 3 / 4; // valid, type casted
i = a; // valid, type casted

var indexable: { [i: int]: bool } = {};
indexable[n] = true; // error
indexable[i] = true; // valid
indexable[i/2] = true; // valid, type casted
indexable[a] = true; // valid, type casted

function logInt(i: int) {
  console.log(i);
}

would emit

var n;
var i = i | 0;
var a = 1.2;
i = 1.1 // error;
i = n // error
i = (3 / 4 ) | 0; // valid, type casted
i = a | 0; // valid, type casted

var indexable= {};
indexable[n] = true; // error
indexable[i] = true; // valid
indexable[(i / 2) | 0] = true; // valid, type casted
indexable[a | 0] = true; // valid, type casted

function logInt(i: int) {
  i = i | 0;
  console.log(i);
}

There will perhaps be a problem with generic and method but I guess the compiler could in this case type cast when passing the parameter:

function add<T>(a: T,b: T): T {
  return a + b;
}  

var a = add(1, 2); // a is number value 3
var b = add<int>(1/2, 2); // b is int, value 2
var c = add(1/2, 2); // c is number, value 2.5

emit :

function add(a, b) {
  return a + b;
}
var a = add(1, 2); // a is number value 3
var b = add<int>((1/2)| 0, 2);
var c = add(1/2, 2); // c is number, value 2.5

also perhaps the compiler should always infer 'number' if there is not explicit type annotation

var n = 3 //number
var i: int  = 3 //int

[RyanCavanaugh]

Great start; thanks for the examples. I have some follow-up questions

Compat of literals vs divide expressions

i = 1.1; // error;
i = 3 / 4; // valid, type casted

By what rule is the first line an error, but the second line OK? I have to assume that the type of 1.1 is still number, and that the type of 3/4 is still number, so from a type system perspective there's no difference there.

var indexable: { [i: int]: bool } = {};
indexable[n] = 3; // error
indexable[i] = 3; // valid

I don't understand either of these. First, 3 is not assignable to bool, so the second assignment should definitely fail. Second, indexible[n] being an error implies that indexible[0] would also be an error (0 and n are of the same type), which is very problematic.

Treatment of optional int parameters

The proposed emit of i = i | 0; implies that undefined and null values are implicitly converted to zero. This makes optional int parameters very dangerous, because you couldn't check them for undefined. How would you deal with that?

Emit locations for | 0

Can you clarify the rules for where exactly | 0 would be emitted?

[fdecampredon]

Compat of literals vs divide expressions

i = 1.1; // error;
i = 3 / 4; // valid, type casted
By what rule is the first line an error, but the second line OK? I have to assume that the type of 1.1 is still number, and that the type of 3/4 is still number, so from a type system perspective there's no difference there.

Ok I guess my example were not really clear, what I meant is :
assigning a number value to a variable explicitly typed as int should not be allowed :

var i: int;
var n: number;
i = n; //error;
i = 1.1 //error

However the division of 2 int-compatible values is contextually typed to int in place where the compiler expect anint

var i: int;
var i1: int;
i = i / i1 // valid and type casted because `i` and `i1` are `int-compatible`
i = 3 / 4 // valid and type casted because `3` and `4` are `int-compatible`

var indexable: { [i: int]: bool } = {};
indexable[n] = 3; // error
indexable[i] = 3; // valid
I don't understand either of these. First, 3 is not assignable to bool, so the second assignment should definitely fail.

I made an error in this example a correct example would be :

indexable[n] = true; // error
indexable[i] = true // valid

I just wanted to notify that the same rules applied for variable assignment and indexing (and it should also apply to parameters) I'll update the example right now.

Second, indexible[n] being an error implies that indexible[0] would also be an error (0 and n are of the same type), which is very problematic.

Not really in the same way that var i: int = 0 is valid because 0 is contextually typed to int here indexible[0] is valid because 0 is contextually typed to int.
n however is explicitly typed to number and so indexible[n] is an error because number is not compatible with int.

Emit locations for | 0

Can you clarify the rules for where exactly | 0 would be emitted?

there is 4 cases where the compiler must emit |0

• in case of uninitialized variables var i: int emit : var i = i | 0;
• When assigning division of int-compatible values
• When assigning value typed as any
• Parameter specified as int should be type-casted at the beginning of the function block

Treatment of optional int parameters

The proposed emit of i = i | 0; implies that undefined and null values are implicitly converted to zero. This makes optional int parameters very dangerous, because you couldn't check them for undefined. How would you deal with that?

In fact I would tend to think that having for rule that :
int are always initialized and 0 by default
like in other typed language like ActionScript would make sense for me.
If you look at one of the example you can see that var i: int emit : var i = i | 0; so even for variable int are never undefined nor null.
However that part is completely optional, and the compiler could just type cast parameters passed to the function in the same way that it would do for assignment and indexing :

function logInt(i: int) {
  console.log(i);
}
var t: any = 3;
logInt(t);

function logInt(i) {
  console.log(i);
}
var t = 3;
logInt(t|0); // t is any so type casted

Still I think that emitting that cast at the beginning of the function could allow JIT compilers to perform some optimization. But that's perhaps another topic.

[RyanCavanaugh]

Diving into the contextual typing, it sounds like you have a few new rules:

• An indexing expression whose operand has an int indexer is contextually typed with the type int
• The type of a numeric literal is number unless its contextual type is int and it is an IntegerLiteral, in which case its type is int

Is that right? Maybe elaborate some examples here.

Going back to this example:

var i: int;
i = 3 / 4 // valid and type casted because `3` and `4` are `int-compatible`

What's the emit here? i = 3 / 4 or i = (3 / 4) | 0? Both are bad -- one introduces a floating point number into an int, and the other breaks JavaScript compatibility (this is not something we would do).

[fdecampredon]

var i: int;
i = 3 / 4 // valid and type casted because 3 and 4 are int-compatible
What's the emit here? i = 3 / 4 or i = (3 / 4) | 0? Both are bad -- one introduces a floating point number into an int, and the other breaks JavaScript compatibility (this is not something we would do).

For me it seems logic than when you assign something to an int it gets automatically type casted so I would say that :

var i: int;
i = 3 / 4 // valid and type casted because `3` and `4` are `int-compatible`

would be translated to :

var i;
i = (3 / 4) | 0;

However that division part of what I proposed is just a tool to avoid boilerplate of manually casting it, if that implicit cast is not something desired the compiler could just report an error.

[fdecampredon]

Ok trying to summing up of the discussion I obtain the following rules :

• there is a new primitive type int representing integer values
• int is not compatible is always initialized to 0 and cannot be undefined, to obtain such behavior the compiler will type cast int values with |0 in place where it might become a non-int value :

var i: int; 
function addInt(a: int, b: int) {
  return a + b;
}
var a: any = 3.5;
i = a;

emit:

var i = i | 0;
function addInt(a, b) {
  a = a | 0;
  b = b | 0;
  return a + b;
}
var a = 3.5;
i = a | 0;

• The type of a numeric literal is number unless its contextual type is int and it is an IntegerLiteral, in which case its type is int :

var n = 1; // n is number
var i: int = 1; // i is int
i = n; // error

var objWithNumber = { i: 1 }; // objWithNumber type is { i: number; };
var objWithInt: { i: int } = { i: 1 }; // objWithInt type is { i: int };
objWithInt = objWithNumber; // error

function getValue() { return 1; } // getValue type is : () => number
function getInt(): int { return 1; } // getValue type is : () => int
var n1 = getValue(); //n1 is number
var i1 = getValue(); //i1 is int
i1 = n1; //error

• An indexing expression whose operand has an int indexer is contextually typed with the type int

var n: number;
var i : int;
var indexible: { [index: int]: any };

indexible[n]; // error
indexible[i]; // valid
indexible[1]; // valid `1` is here contextually typed to `int`
indexible[1.1]; // error

• operators :
  • int (+, -, *) int is int
  • int / int is number, if we do not include the automatic division type casting
  • number ( |, &, >>, <<, >>>) number is int, important since |0 it will serve as manual typecast for division

[ivogabe]

I have an alternative proposal, which introduces also a double type. This one is more in line with asm.js, for example |0 is not allowed on a number (only integer), you should use ~~ to convert a number to an integer.

Integer & double proposal

This proposal introduces 2 new primitive types: integer and double. Both extends the number type. It was designed for 2 reasons, for compile time type checking and for run time optimalizations (like ASM.js).

Naming

I chose for integer instead of int, because bool has been renamed to boolean in TypeScript, and integer is more in line with boolean than int.

ASM.js

This proposal was designed with asm.js in mind. integer maps to asm's signed and double maps to double.

Values

A double can be everything a number can be except undefined or null, including Infinity, -Infinity and NaN. An integer can be every number without a decimal point. An integer cannot be undefined, null, Infinity, -Infinity nor NaN. number is the only primitive number type that can contain undefined and null.

When you declare a variable with the type double or integer, it will automaticly be 0.

Any number literal that contains no decimal point and does not have an negative exponent after the E (like 9E-4) is an integer. All other number literals are doubles. The following code will throw errors:

var int: integer; // Ok, int will be 0
int = 3.0; // Error: A double cannot be implicitly converted to an integer.
int = 9E-4; // Error: A double cannot be implicitly converted to an integer.
int = undefined; // Error: An integer-unde cannot be undefined.
int = 3; // Ok

var d: double; // Ok, d will be 0.
d = 3; // Error: An integer cannot be implicitly converted to a double.
d = 9E4; // Error: An integer cannot be implicitly converted to a double.
d = 3.; // Ok
d = <double> 3; // Ok

Casts

You can cast between the types number, integer and double. The value will be converted at run time (see Generated JavaScript). When converting to an integer, the number will be truncated, the numbers after the decimal point will be removed. So -1.5 will be converted to -1. A value that cannot be converted by truncating (eg undefined or NaN to an integer) will become 0.

var n: number = 3.5;
var d: double = <double> n; // You need to cast here, otherwise you will get an error 'A number cannot be implicitly converted to a double'.
var int: integer = <integer> d; // int will be 3.

n = undefined;
d = <double> undefined; // d will be 0;

Optional arguments

A optional argument typed as integer or double is allowed. When no default value is given, 0 is used as the default value (because an integer or a double cannot be undefined).

Generated JavaScript

Most expressions will be wrapped with (...)|0 (for integers) and +(...) (for doubles).

Function arguments

Arguments will be reassigned according to the ASM.js spec.

TypeScript:

function foo(a: integer, b: double, c: integer = 3, d: double = 3., e?: integer, f?: double) {
}

JavaScript:

function foo(a, b, c, d, e, f) {
    a = a|0;
    b = +b;
    c = (c === void 0 ? 3 : c)|0;
    d = +(d === void 0 ? 3. : d);
    e = e|0; // undefined | 0 => 0
    f = +f; // +undefined => 0
}

Adding 0 explicitly as the default value should generate the same code as adding no default value.

Function return

The expression of the return statement should be wrapped:

JavaScript:

function foo() {
    return ("complex calculation".length)|0; // Returns integer
}
function bar() {
    return +("complex calculation".length / 3); // Returns double
}

Assigning to a variable

When declaring a variable (integer or double) without assigning a value, it gets the value 0 (since an integer or double cannot be undefined).
When assigning a something to a variable whose type is integer or double, the expression should be wrapped:

TypeScript:

var a: integer = "complex calculation".length;
a = a * 2;
a *= a;

var b: integer; // b will be 0.

JavaScript:

var a = ("complex calculation".length)|0;
a = (a * 2)|0;
a *= a|0;

var b = (0)|0; // b will be 0.

Typecasting

A cast to double is wrapped with +(...) and a cast to integer is wrapped with ~~(...), because the asm.js spec does not allow a double on the | operator.

TypeScript

var n: number = 4.5;
var d: double = <double> n;
var int: integer = <integer> n;

JavaScript

var n = 4.5;
var d = +(n);
var int = ~~(n);

A cast from anyting to number, from integer to integer or from double to double will emit not extra JavaScript.

Operators

Unary

• +number => double
• -number => double (since -undefined = NaN and -null = 0)
• -integer => integer
• ~integer => integer
• !number => boolean

Binary

• integer +, - or * integer => integer
• number +, - or * number => double (since undefined + undefined = NaN)
• number / number => double (since undefined / undefined = NaN)
• integer |, &, ^, <<, >> or >>> integer => integer
• number <, <=, >, >=, ==, !=, === or !== number => boolean
  Note that you cannot apply the /= assignment operator on an integer.

Generated errors

An error is thrown when:

• an integer or double is expected but something else is given (eg number or undefined).
• you apply an illegal assignment operator on a number (eg /= on an integer or |= on a number).

[danquirk]

How does this existing TypeScript code behave? Is it now an error when integer is inferred for x?

var x = 1;
x = 1.5;

It's very strange to add runtime semantics to certain cast operations.

[ivogabe]

Indeed, there needs to be a rule that a non-typed variable declaration won't get the type integer or double, but always number. If you want a variable to be an integer or double, you'll need to specify that explicitly.

I chose for runtime semantics to cast operations because of various reasons. For performance, js engines know better how much space they need to allocate for a number and they know which overload of the + operator is used. Integer calculations are most times faster than floating point ones.

There also needs to be a way to convert the different number types between each other. If you already generate JavaScript for cast operations, why not use a cast to convert a number type? Also this doesn't introduce a new syntax.

An alternative would be to write ~~ or + to convert numbers, but in my opinion the cast look better:

var d: double = 3.5;
var int: integer = <integer> d;
d = <double> int;

// Or

var d: double = 3.5;
var int: integer = ~~d; // Because |0 isn't supported on doubles according to the asm.js spec.
d = +d;

[mbebenita]

How do you propose to deal with constants in an expression, for instance what does 1 + 2 compile to. Is it (1 + 2) | 0 or is it left as is. If the constants are integers, then you'll need to insert the coercion, which will break existing TypeScript code. If you assume that they are numbers then the expression x + 1 will always be of type number.

It feels to me like you need to buy into the asm.js type system explicitly, so either do something like <integer> 1 + <integer> 2, or come up with a new syntax for declaring typed constants. Otherwise existing TS/JS code will break.

[ivogabe]

1 + 2 is integer + integer, so it becomes integer, and it will be wrapped with (...)|0 in certain situations. number + integer falls back to number + number (since integer extends number) so this will return a double, and double also extends integer so it will be backwards compatible. Example:

Compare it to this OOP example:

interface Base { // number
  base: string;
}
interface Foo extends Base { // double
  foo: string;
}
interface Bar extends Base { // integer
  bar: string;
}

function add(first: Base, second: Base): Foo;
function add(first: Bar, second: Bar): Bar;
// ... implementation of add ...
var base: Base, bar: Bar;
base = add(base, bar); // first signature, returns Foo, which extends Base.

When you call add in this example with a Base and a Bar, it'll return a Foo. The + operator is overloaded the same way in my proposal.

number + number => double because:

undefined + undefined = NaN;
null + null = 0;
null + undefined = NaN;
undefined + 2 = NaN;
null + 2 = 2;

[electricessence]

This is awesome. PLEASE make ints and doubles!
Obviously a simple example of this is array indexes should always take ints.