D design problem on platforms with <32 bit pointer width

[Dukc]

On Sunday, 20 August 2023 at 19:13:36 UTC, Walter Bright wrote:
> So, I propose the following modification for 16 bit code 
> generation:
>
> Keep integer promotion, but have it promote to short rather 
> than int. I haven't thought about it deeply, but first 
> impression says that it will resolve most of the issues.

"for 16 bit code generation" - meaning, the int promotion target 
won't change for 32-bit platforms?

>
> This will require changing many of the ints in the source code 
> to shorts. How onerous that would be, I do not know. One could 
> do something like:

I think this is otherwise actually good, but has one annoying 
trait left: integer literals. To make you code portable, you'll 
have to wrap your integers when doing pointer arithmetic or 
handling array lengths: `ptr += size_t(3)` or `new 
ubyte[oldArr.length + size_t(3)]`. But this one does not have the 
performance problems of the 32-bit size_t solution I initially 
was in favour of.

Still, I'd prefer changing the value range propagation rules 
instead as that:
  - works exactly the same way regardless of pointer width.
  - does not mandate wrapping in literals with `size_t` or 
`ptrdiff_t` constructor.
  - makes non memory address related 8 and 16 bit arithmetic more 
confortable to do while there.

But either solution is a lot better than the current situation, 
at least when going by what the spec says.