Range size larger than integer range

[TheHllm]

Description

Ranges can have a size larger than the allowed range for Integers. This can be used to proof that, oppsed to what some tests may claim, TScripts for loops are turing complete (at least in the only tscript runtime).

To Reproduce

print(Range(-2, 2147483646).size());

Arrays and strings however are safe(r) since it would be impracticable to create one of them with a size larger than 2147483647. They are also respectivly bounded by 2^32 and 2^53 -1.

[TGlas]

The compelling part of your example is this:

print(Type(Range(-2, 2147483646).size()));     # prints <type Integer>

You found a way to construct an integer value outside of the allowed range, and that's clearly a bug. In #81 you propose to fix it by disallowing large ranges. You are right that strings and arrays are less suspectible to the same problem, but the JS spec allows these structures to grow really huge, so when fixing ranges we should consequently also fix string, array and dictionary. I agree that practically speaking there is no need, but it would be odd to leave this open.

I see two possible remedies:

• limit the size of ranges and containers to the largest integer (as you did in Fixed ranges size larger than an integer #81), or
• let the return value of size() overflow.

The principle of least surprise and the fact that these limits are quite generous indicate that the first solution is preferable. I'll merge #81 but leave this open, since strings and containers should be addressed eventually (low priority).

[Jartreg]

@TGlas if you wanted to keep this open you might need to reopen it

[TGlas]

Yeah, obviously :) Thanks.

[manuel-fischer]

An alternative could be to think about a big integer type like in Python, that is only limited by the available memory.

[TGlas]

That's true, it would nicely solve the issue in the language. However, one of the learning goals is to understand the two-complement representation of signed integers. Understanding the inner working mechanisms of integers would then become more involved. Code complexity would also increase, since all integer operations need to be implemented manually (+, -, *, //, %, not, and, or, xor, as well as conversion to floating point numbers). I am not sure that it is worth it.

[Jartreg]

While JavaScript does have a BigInt type, I'd agree that adding a whole new type of numbers just to solve this issue might be out of scope for a language intended for beginners.

[TGlas]

Good to know, I had no idea! Anyway, I agree.