size_t.sizeof == 2 && __LINE__.sizeof == 4

[Luís Marques via Digitalmars-d]

Hello,

We have a few cases where __LINE__ is assigned to a size_t. For 
instance:

     class Exception : Throwable
     {
         @nogc @safe pure nothrow this(string msg, string file = 
__FILE__, size_t line = __LINE__, Throwable next = null)
         {
             super(msg, file, line, next);
         }

__LINE__ is currently defined as 32 bits in LineInitExp 
(Type.tint32). For 32 and 64 bit targets these assignments are 
not a problem (they are either a plain copy or a 0 extension), 
but for 16 bit targets (e.g. MSP430) these are problematic 
because you can't assign the 32-bit __LINE__ value to the 16-bit 
size_t line variable without a cast.

IMO, using size_t for lines is silly, for several reasons:

1. There's no reason why 16-bit targets can't have source code 
with more than 64 K lines;

2. There's probably no good reason to support more than 4 B lines 
of source code;

3. If we *do* want support more than 4 B lines of source code, 
there's no reason to make that support conditional on whether the 
*target* is 32- or 64-bit. Even if we assume the compiler has to 
hold all of the lines in main memory, that's a property of the 
host, not the target.

If see a few ways to move forward:

1) Change `size_t line` to `int line`. The line is already 32 
bits under the covers (and I don't see the need to change that). 
The only issue might be code breakage.

2) Make __LINE__ 16-bit for 16-bit targets. I don't think this 
option makes much sense.

3) Create a line_t type (in object.d?). Make it 32-bit for 16- 
and 32-bit targets, and 64-bit for 64-bit targets. That's for 
avoiding breakage, not because >4 B lines is actually needed, IMO.

I suggest following 3 -- even though I think option 1 would be 
the right one for a day-1 design. (This option also allows 
eventually making line_t 32-bit on 64-bit targets, if people 
start using line_t instead of size_t).

What do you think?

Luís