Walter:
Instead of adding more language features,<
Perhaps you can't solve this problem in a sufficiently clean way
without adding language features (and a assume() is not the
solution, see below).
---------------------
Ola Fosheim:
Conflating run time debug checks with programmer provided
guarantees sounds dangerous. Call it "assume" not "assert" then.
But this still missed the point. I am not interested in
annotations, in this thread I am not asking for a built-in
assume() (or for some weird kind kind of assert() that is much
worse).
Let's go back to the second example I've shown:
void main() {
import std.stdio, core.checkedint;
ubyte x = 100;
ubyte y = 200;
bool overflow = false;
immutable result = muls(x, y, overflow);
assert(!overflow);
writeln("Product: ", result);
}
Here I am not willing to add an assume(). Here at the call point
of muls() x and y have a full range of ubytes, so the range
analysis tell the compiler their product will not overflow, so it
can replace the muls() with a regular product and leave overflow
untouched. This is faster.
The same kind of optimization is desired for a SInt or other
library-defined types. So the point of this discussion is how to
do this. The problem is that the compiler has some static
information about ranges, but to optimize away user-defined types
such information needs to be read and given to "static ifs" to
replace the calls to muls() to calls to regular operations.
Bye,
bearophile