It has the same numeric semantics as Javascript. Javascript does not have a 64-bit integer.

This is not about the lack of 64 bit integers. Dart can have 32 bit or 31 bit or 30 bit integers or whatever it wants.

But mathematically it doesn't make sense to have an int type which does not represent integers consistently. Clearly Javascript can represent 2^31 as a positive integer. In fact it can represent 2^53 as a positive integer (of course in reality it uses a double precision float) as can be verified by typing (1<<20)x(1<<20)x(1<<13) into a Javascript console.

So why is (1<<31) not positive? This is surely something which needs to be fixed in Dart. If they want to make (1<<31) negative, then (1<<30) + (1<<30) should equal (1<<31) and so it should also be negative. Otherwise doing arithmetic is difficult and error prone, which makes it unsuitable as a target for other languages which want to compile down to Dart.

In fact, not having at least 32 bit unsigned integers would be a major drawback. For efficiency reasons you want these to be handled directly by your VM using integer assembly instructions. This is the only way that you'll ever implement efficient bignum libraries for example which require FFT's which necessarily use integers that are an exact multiple of 32 bits in length (Z/pZ for p = 2^(2^L) + 1 usually, where 2^L is a multiple of 64 at least, usually).

From the Dart documentation:

"Integers are not restricted to a fixed range. Dart integers are true integers, not 32 bit or 64 bit or any other fixed range representation. Their size is limited only by the memory available to the implementation"

So they obviously haven't got this right. Not only does their implementation not implement this, but it is completely broken anyway because you certainly won't be more efficient than Javascript if your integers are implemented as bignums instead of floats.