Bug in ^^

[Brett]

On Tuesday, 17 September 2019 at 19:19:46 UTC, Timon Gehr wrote:
> 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.

And this is why compilers should do everything they can to reduce 
problems... it doesn't just effect one person but everyone that 
uses the compiler. If the onus is on the programmer then it means 
that a very large percentage of people(thousands, 10's of 
thousands, millions) are going to have to deal with it as you've 
already said, they are lazy, so they won't.

>
>> 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.)

No, that is not the right behavior because you've already said 
that wrapping is *defined* behavior... and it is not! One if we 
multiply two numbers together that may be generated at ctfe using 
mixins or by using a complex constant expression that may be near 
the upper bound and it happens to overflow? Then what?

You are saying it is ok for undefined behavior to exist in a 
program and that is never true! Undefined behavior accounts for 
100% of all program bugs. Even a perfectly written program is 
undefined behavior if it doesn't do what the user 
wants/programmer wants.

The compiler can warn us at compile time for ambiguous cases, 
that is the best solution. To say it is not because wrapping is 
"defined behavior" is the thing that creates inconsistencies.