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

Reply via email to