Integer overflow and underflow semantics?

[Don via Digitalmars-d]

On Monday, 21 July 2014 at 21:10:43 UTC, Artur Skawina via 
Digitalmars-d wrote:
> On 07/21/14 21:53, via Digitalmars-d wrote:
>> On Monday, 21 July 2014 at 19:33:32 UTC, Artur Skawina via 
>> Digitalmars-d wrote:
>>> Disallowing integer overflow just at CT is not (sanely) 
>>> possible
>>> in a language with D's CTFE capabilities. (Would result in 
>>> code
>>> that compiles and works at runtime, but is not ctfe-able)
>> 
>> I'd like to see compile time _constants_ be unbounded rational 
>> numbers with explicit truncation. It is when you assign it to 
>> an in-memory location that you need to worry about bounds. The 
>> same goes for calculations that doesn't do division.
>> 
>> No need to copy the bad parts of C.
>
> Actually, C/C++ could get away with treating overflow during 
> constant
> folding as an error (or at least emitting a warning) because of 
> the
> lack of CTFE (and no templates in C's case). The code will 
> either
> compile or it won't.
> For D that is not possible -- if an expression is valid at 
> run-time
> then it should be valid at compile-time

Why do you think that? There are many cases where that is not 
true. Comparing pointers to two unrelated objects will work at 
runtime, but causes an error in CTFE. You can read global 
variables at runtime, not in CTFE. Etc.

The converse is true, though -- if it works at CTFE, it must work 
at runtime.


Disallowing integer overflow in CTFE could certainly be 
implemented. It's not a difficult experiment to run. It would be 
interesting to see how many instances of overflow are bugs, and 
how many are intentional.