Bug in ^^

Patrick Schluter Patrick.Schluter at bbox.fr
Tue Sep 17 19:56:48 UTC 2019

On Tuesday, 17 September 2019 at 19:31:49 UTC, Brett wrote:
> 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.

Brett, read the fine manual. The promotion rules [1] and the 
usual arithmetic conversions [2] are explained in detail.
The reason why the grammar is as it is, has to do that the 
language was not defined in a void. One of the goals of the 
development of D is to be a successor of C. To reach that goal, 
the language has to balance between fixing what is wrong with its 
predecessor and maintaining its legacy (i.e. not estranging 
developers coming from it by modifying rules willi nilli).
The thing with integer promotion and arithmetic conversions is 
that there is NO absolute right or wrong approach to it. The C 
developers chose to privilege the approach that tended to 
maintain the sign when mixing signed and unsigned types, other 
languages took other choices. One of the stated goals of the D 
language that Walter has stated several times, is that D 
expression that are also valid in C, behave like C, to minimize 
the surprize for people coming from C (or C++).

[1]: https://dlang.org/spec/type.html#integer-promotions
[2]: https://dlang.org/spec/type.html#usual-arithmetic-conversions

More information about the Digitalmars-d mailing list