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