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
