Yes, from a users perspective in current julia yes. I was talking about it from the point of view that the @assert macro in Base would work like this. For this cases I think it would be better to have a startup option with two different sysimg and precompilation directories. The downside being that you can’t toggle it in a session.
1 Like
For this cases I think it would be better to have a startup option with two different sysimg and precompilation directories.
Even the bit-polishing performance-obsessed me is thinking this could
be a bit of an overkill for @assert, XD. If we grouped all training
wheels and/or non-essentials (@assert, bound checking, TimerOutputs,
etc…), then maybe having this infrastructure to run the code with or
without them would be justified. Maybe.
Is ToggleableAsserts.jl still the state-of-the-art to use assertions in high-performance-code?
2 Likes
Very interesting. If I am in need of this kind of check again, I will
maybe try to update the package to make them work again.
Great solution.
I ended up adding something like the following to my module’s __init__() function:
@eval asserting() = get(ENV, "ENABLE_ASSERTS", "0") == "1"
Why does that need to be in the __init__ function (and use @eval 
)?
1 Like