On Monday, 5 March 2018 at 18:44:54 UTC, Joseph Rushton Wakeling
wrote:
On Saturday, 3 March 2018 at 16:33:00 UTC, Martin Nowak wrote:
Doesn't really work that way, we can disable assertions, in
contracts, out contracts, and invariants. But not assertions
in some contexts while leaving them enabled in other contexts.
At least not without modifying all related codegen and
introducing context queries (e.g. think mixin templates).
That's a shame, but presumably the fine-grainedness could be
extended at some point.
Question: what would -release=assert do to unittests? Would it
not touch them at all? Or would it disable all asserts
including in unittests?
From memory, it would turn off asserts even in unittests. You
could raise a bug against gdc for that as it's a reasonable
suggestion.
FWIW -release=assert,in,out,invariant fits out needs well
enough.
Just the use-case that someone wants to disable asserts in
functions but still wants to use contracts, required to use a
replacement for assert in contracts and invariants.
Yea, there are obviously workarounds. I think the main concern
from my side is to not have hierarchical assumptions about what
gets turned on or off, and AFAICS
-release=assert,in,out-invariant pretty much fits that.
N.B: GDC has -f[no]-release, -f[no-]assert, -f[no-]invariant,
-f[no-]preconditions, and -f[no-]postconditions (-f[no-]in and
-f[no-]out were removed as they are a little too vague). And it
doesn't matter which order you pass them in, if an option is
explicitly set, then they do not get turned on/off by -frelease.
