Integer overflow and underflow semantics?

[Artur Skawina via Digitalmars-d]

On 07/23/14 09:16, Don via Digitalmars-d wrote:
> On Monday, 21 July 2014 at 21:10:43 UTC, Artur Skawina via Digitalmars-d wrote:

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

Obviously, any allowed operation must still yield a meaningful result.
The CTFE restrictions you list could actually be relaxed. Eg __gshared
object pointers could be (more) exposed; static immutable objects already
are exposed, it would be possible to give read-only access to mutable
ones too. (Not that I'm suggesting doing that)

But the context was _integer arithmetic_ expressions -- those needs to
work at CT exactly like they do at RT. Anything else would mean that
CTFE would be crippled; either some (sub-)programs wouldn't be usable
at CT, or they would give different results. A compromise that would
disallow just some "obviously" wrong expressions is not a real option, 
because D is too powerful (the "wrong" code could itself come from CTFE).

Sure, it would be /technically/ possible to trap on overflow at CT, but
the result wouldn't be sane. And it would make the language even more
complex. Just imagine all the extra posts asking why something doesn't
work at CT. And if OF is allowed in certain situations, then also all
the complaints about the compiler not catching some overflow...

artur