Bug in ^^

Timon Gehr timon.gehr at gmx.ch
Tue Sep 17 19:19:46 UTC 2019


On 17.09.19 19:34, Brett wrote:
> 
> What's more concerning to me is how many people defend the compilers 
> behavior.
> ...

What you apparently fail to understand is that there are trade-offs to 
be considered, and your use case is not the only one supported by the 
language. Clearly, any wraparound behavior in an "integer" type is 
stupid, but the hardware has a fixed word size, programmers are lazy, 
compilers are imperfect and efficiency of the generated code matters.

> Why
> 
> enum x = 100000000000000000;
> enum y = 10^^17;
> 
> should produce two different results is moronic to me. I realize that 
> 10^^17 is a computation but at the compile time the compiler should use 
> the maximum precision to compute values since it actually can do this 
> without issue(up to the a point).

The reason why you get different results is that someone argued, not 
unlike you, that the compiler should be "smart" and implicitly promote 
the 100000000000000000 literal to type 'long'. This is why you now 
observe this apparently inconsistent behavior. If we really care about 
the inconsistency you are complaining about, the right fix is to remove 
'long' literals without suffix L. Trying to address it by introducing 
additional inconsistencies in how code is interpreted in CTFE and at 
runtime is plain stupid. (D currently does things like this with 
floating point types, and it is annoying.)


More information about the Digitalmars-d mailing list