This is a request for comments. I've written it as a Git gist as opposed to forum post because it's pretty long and may warrant some editing at some point.

Link: https://gist.github.com/dukc/04ea4d4a248ff4709f89d5808f67a5fe

Discussion can remain here though.

On Saturday, 19 August 2023 at 10:09:56 UTC, Dukc wrote:

I hate those stupid promotion rules.
Every literal should be of the smallest type that can represent it
(e.g. 0..255 should be ubyte, 256..65535 should be ushort, etc., -1..-127 should be byte, -128..-32767 should be short, ...) and can be promoted to whatever is needed implicitly.
Yes, I think -128 should NOT be byte. this would stupid and error prone because abs(-128) cannot be byte. In fact 0x80 should be the NaN of byte, 0x8000 the NaN of short, etc. instead of exceptional negative values.
Also the operations should stay within the same type (largest of the involved operands), e.g. short+short = short.
Internally it may be best to work with the machine word size (whatever that is - could be even 8 bit) but should be truncated to the intended result if not otherwise stated (via cast).

On Saturday, 19 August 2023 at 10:43:59 UTC, Dom DiSc wrote:

It's not quite that simple. Consider:

auto x = 40;
// 1600 now, 64 with your rules
x *= x;

Inference happens at initialisation of the variable. In this case, it's ubyte because nothing bigger is needed to hold the initialisation value. Inference can't detect what is needed later, that is why int literals default to 32 bits.

On Saturday, 19 August 2023 at 10:09:56 UTC, Dukc wrote:

Nice, thanks.
I've added my comment (make a table of all interesting cases!) to the gist.

cheers,
Johan

On Saturday, 19 August 2023 at 10:55:45 UTC, Dukc wrote:

It would be better if 8 bit or 16 bit systems provide some sort of segmented pointer such that allocating 32 bit would be require a struct Ptr {ubyte firstSegment, ubyte secondSegment, ubyte thirdSegment, ubyte fourthSegment} on 8 bit architecture and struct Ptr {ubyte firstSegment, ubyte secondSegment} on 16 bit systems.

On Saturday, 19 August 2023 at 12:58:48 UTC, sighoya wrote:

ubyte shold be ushort, sorry

On Saturday, 19 August 2023 at 10:55:45 UTC, Dukc wrote:

auto x = 40;
// 1600 now, 64 with your rules
x *= x;

Sorry, but if you say nothing about which type you want, you may always be surprised unless you know the inference rules.
You could have written

int x = 40;

which incidentally is even one character shorter. And then you have the guarantee that you have 31 bit (+sign) for your calculations - no matter on which hardware you're working.
In your example you expect the C rules. But if the program runs on a 8-bit system, what you get will be a (signed) byte! So the result of your square may be even negative, breaking a whole lot of further assumptions on the result.