I would find it very useful.
Rather than writing
if (std.debug.runtime_safety) assert(g < self.first_rows.len());
I would like to write
assert_safe(g < self.first_rows.len());
code is cleaner, easier to read.
I am on 0.17.0
I would find it very useful.
Rather than writing
if (std.debug.runtime_safety) assert(g < self.first_rows.len());
I would like to write
assert_safe(g < self.first_rows.len());
code is cleaner, easier to read.
I am on 0.17.0
It would first be helpful to understand why you’re doing:
if (std.debug.runtime_safety) assert(g < self.first_rows.len());
Note that there has been a lot written about assert that you might be interested in reading:
to run assert checks only during zig optimize=.safe and not other optimize levels
I think you’d benefit from reading You Must Fix Your Asserts | Loris Cro's Blog
Hi!
I assume you want to make sure that the argument to assert_safe is not evaluated, for example because it is slow or doesn’t get optimized out.
This is not directly possible in Zig because it does not have macros, the argument to assert_safewill still be evaluated.
If this is not your goal, see the linked articles.
these are not equivalent, in the first snippet self.first_rows.len() is behind a comptime condition, so it will certainly not be called if that condition is false.
in the second it is not, meaning that if the optimiser can’t determine if it can remove that call, then it will remain in the second case; this is important if the call is expensive.
At this point assert has become the canonical Ziggit topic ![]()
I think the best way to achieve this is with the following:
const assert: ?fn (ok: bool) void =
if (std.debug.runtime_safety)
std.debug.assert
else
null;
if (assert) |x| x(g < self.first_rows.len());
This is a bit less prone to accidental mistakes than other equivalent forms like assert((comptime disable_assert) or expensiveCheck()).
But I’d also second the recommendation to read Loris’s blog post on the subject. It is normally a good idea to leave your assertions enabled even in your release builds (perhaps with the exception of checks that are so expensive that they show up in a profiler).
At this point
asserthas become the canonical Ziggit topic
that and Traits/comptime interfaces. @squeek502’s list is a good compilation of the discussions about Assert.
yes,
I have a table (like a data frame), I use asserts that runs on per-column basis.
I could add many per-group and some per-row asserts, but it will impact all 4 build optimizations level in make test. My goal is running those slow asserts (for each row) on just safe level, and not on 3 others.