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

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).