The problem, as I see it, is nobody actually cares about this.
Why would I say something so provocative? Because I've seen D
programmers go to herculean lengths to get around problems they
are having in the language. These efforts make a strong case
that they need better language support (UDAs are a primo
example of this). I see nobody bothering to write a CheckedInt
type and seeing how far they can push it, even though writing
such a type is not a significant challenge; it's a
bread-and-butter job.
I disagree with the analysis. I do want overflow detection, yet I
would not use a CheckedInt in D for the same reason I do not
usually use one in C++: without compiler support, it is too
expensive to detect overflow. In my C++ I have a lot of math to
do, and I'm using C++ because it's faster than C# which I would
otherwise prefer. Constantly checking for overflow without
hardware support would kill most of the performance advantage, so
I don't do it.
I do use "clipped conversion" though: e.g.
ClippedConvert<short>(40000)==32767. I can afford the overhead in
this case because I don't do type conversions as often as
addition, bit shifts, etc.
The C# solution is not good enough either. C# throws exceptions
on overflow, which is convenient but is bad for performance if it
happens regularly; it can also make a debugger almost unusable.
Some sort of mechanism that works like an exception, but faster,
would probably be better. Consider:
result = a * b + c * d;
If a * b overflows, there is probably no point to executing c * d
so it may as well jump straight to a handler; on the other hand,
the exception mechanism is costly, especially if the debugger is
hooked in and causes a context switch every single time it
happens. So... I dunno. What's the best semantic for an overflow
detector?
