A)
Requiring a construct such as Checked!int is too complicated for the user
in general as it requires a lot of code change from the user. It may be
useful in certain cases but overflow bugs will crop up in unexpected places.

B)
To help finding such bugs, introduce a special version identifier for
checking arithmetic overflow (eg -version=check_arithmetic_overflow) (no
new compiler flag syntax, just a built in version identifier).

C)
It shouldn't be implied by -debug flag as it may slow down debug code
significantly, making debug code too slow to be useful. Conflating the
"debug" statements and arithmetic overflow is a bad idea; debugging
shouldn't be an all or nothing option.

D)
More generally, there's a trade-off between keeping the number of compiler
flags low for simplicity and having and having more flags for more
expressiveness. I feel dmd is trying too hard to keep the number low.
There's a reason why gcc, clang etc have so many flags, which gives user
finer control. There should be a good middle ground: the defaults should be
simple (optimize vs debug), but when searching for bugs, optimizing or
dealing with deprecated constructs, we want flexibility.

F)
Finally, some code may indeed depend on arithmetic overflow, and shouldn't
be affected by -version=check_arithmetic_overflow. Maybe we need a way to
"unset" a version identifier; here's a possible syntax:

----
module test;
version = check_arithmetic_overflow; //existing syntax
void fun(){}

version -= check_arithmetic_overflow; //new syntax
void fun2(){} //now check_arithmetic_overflow is unset
----

This would be very useful in many ways, eg make some code run fast while
the rest is in debug mode (otherwise the debug code would be too slow).



On Thu, May 23, 2013 at 9:13 PM, Marco Leise <marco.le...@gmx.de> wrote:

> Am Fri, 24 May 2013 01:35:42 +0200
> schrieb "Peter Alexander" <peter.alexander...@gmail.com>:
>
> > What about code that relies on overflow? It's well-defined
> > behaviour, so it should be expected that people rely on it (I
> > certainly do sometimes)
>
> See my post about Delphi's approach. It could be disabled in D
> using pragma(), UDAs or even scopes.
>
> --
> Marco
>
>

Reply via email to