Evaluate constant expressions at compile-time

[perlun]

Moved to GitLab

Please continue to the new version of this issue here: https://gitlab.perlang.org/perlang/perlang/-/issues/352. The GitHub page you are currently reading will not contain the latest information on this issue.

---

Originally posted by @perlun in #70 (comment):

We should give this some focus; it's quite absurd that the current expression var l = 2147483648; print(l.get_type()); will create an implicitly typed uint variable which is impossible to specify with an explicit type. I.e. you must use type inference for this; the uint type simply does not exist in the language yet.

This should now be in a much better shape. All "implicit" types below which can get created when parsing integer literals are now also able to be specified explicitly. We no longer have to be ashamed of ourselves. 🙂

perlang/src/Perlang.Parser/NumberParser.cs

Lines 61 to 80 in 3320760

	if (value <= Int32.MaxValue)
	{
	return new IntegerLiteral<int>((int)value);
	}
	else if (value <= UInt32.MaxValue)
	{
	return new IntegerLiteral<uint>((uint)value);
	}
	else if (value <= Int64.MaxValue)
	{
	return new IntegerLiteral<long>((long)value);
	}
	else if (value <= UInt64.MaxValue)
	{
	return new IntegerLiteral<ulong>((ulong)value);
	}
	else // Anything else remains a BigInteger
	{
	return new IntegerLiteral<BigInteger>(value);
	}

An incredibly interesting question is what should happen when we start implementing the smaller integer types, like short, ushort and byte. Should we start coercing integer literals to the smallest possible type even in that case? It may sound like the obvious right thing to do if you don't think about it so much, but it has some utterly weird consequences. For example, if we would coerce things to byte just because we are dealing with small integers, the following assignment:

var v = 150 + 150;

...would not lead to the v variable being assigned to 300, but it would be the left-most 8 bits of the 300 (since all the other bits would be silently discarded). In other words, 44. This would be extremely confusing to about 99.9% of what any user would reasonably expect from the language.

One way to deal with it: special-case integer literals and say that "never implicitly type the result of an expression to something smaller than an int". But that will cause its own problems. Imagine the following example program:

var b: byte = 255;
var s: short = 32767;
var u: ushort = 65535;

If we go with the idea described above, all of these assignments will fail because the integer literals will be too large. This is a consequence of us not doing compile-time evaluation of constant expressions. We should, really, since it will be more or less required to be able to provide a great user experience when dealing (small) integer literals.