It cannot be named. static assert (long.min == -9223372036854775807L); // Error: static assert (-9223372036854775808L == -9223372036854775807L) is false static assert (long.min == -9223372036854775808L); // Error: signed integer overflow
(In reply to comment #0) > It cannot be named. > > static assert (long.min == -9223372036854775807L); > // Error: static assert (-9223372036854775808L == -9223372036854775807L) is > false > > static assert (long.min == -9223372036854775808L); > // Error: signed integer overflow I don't think this has anything to do with voldermort, and this works just fine: void main() { long a = -2L^^63; assert(a == long.min); long b = long.min; assert(b == long.min); } It sounds more like an interpretation error, whereas *writing* "-9223372036854775808L;" causes an error. My *guess* is interprets the decimal number into a long, and afterwards, the sign is applied. This chokes in this particular case, because the valid range for longs is [-2^^63, 2^^63-1], so the interpreted number overflows before the compiler has a chance to apply the sign: long a = 9223372036854775808L; //WRONG long b = -9223372036854775808L; //LEGAL But that's just speculation on my part.
(In reply to comment #1) > (In reply to comment #0) > > It cannot be named. > My *guess* is interprets the decimal number into a long, and afterwards, the > sign is applied. This chokes in this particular case, because the valid range > for longs is [-2^^63, 2^^63-1], so the interpreted number overflows before the > compiler has a chance to apply the sign: Yes, of course that's what's happening. It is a number you cannot write as a literal, you can only use a euphemism like "long.min" or "-2L^^63".
Although no surprise, it might be worth noting that mixin("static assert(long.min==" ~ long.min.stringof ~ ");"); causes the "signed integer overflow" error, too.
We could introduce arbitrary precision integer literals to fix this, but that's an enhancement. This works the same as it does in C.
*** Issue 13606 has been marked as a duplicate of this issue. ***
*** Issue 13842 has been marked as a duplicate of this issue. ***
I don't think this is a bug. I think it's operator precedence. long(-9223372036854775808UL) or long l = -9223372036854775808UL Just a little unintuitive is all.
*** Issue 13762 has been marked as a duplicate of this issue. ***
Nowadays, the `L` suffix is not required anymore, so the following compiles just fine: ``` static assert (long.min == -9223372036854775808); ``` I was about to say that we should fix this for C compatibility, but C has the same issue, as Daniel pointed out: ``` int main () { long long a = -9223372036854775808LL; return 0; } ``` ``` foo.c:3:20: warning: integer literal is too large to be represented in a signed integer type, interpreting as unsigned [-Wimplicitly-unsigned-literal] long long a = -9223372036854775808LL; ^ 1 warning generated. ``` This sounds like a good entry for a FAQ. Closing as WONTFIX.