Open ratchetfreak opened 2 years ago
Do you have an actual example (with benchmark numbers) where this helps the compiler / optimizer or is it hypothetical at this stage?
If we do do this, one subtlety is that Wuffs-side asserts work in ideal numbers but compilers work in fixed-sized integers. assert (x + 1) > x
is valid for mathematical integers but isn't always true for uint32_t
integers (and for signed fixed-size integers, this might even be "undefined behavior").
It's hypothetical at this stage.
and yeah that does complicate matters
Can there be an option to convert wuffs-side asserts into asserts in the generated code?
This could be a macro which lets the user code pick which behavior to have for them.
So the assert can translate into nothing (like it is now), or a full error like
if not cond {return "#internal error: failed assert";}
, or an actualassert(cond);
, or even anassume(cond);
.Theoretically the compiler should be able to optimize out all these checks but there will be cases where it cannot make the assumptions necessary like across a yield. This in turn could help the optimizer figure out better options based on the invariants that are present in wuffs but not present in the backend.