DIP 1006 - Preliminary Review Round 1

[Iain Buclaw]

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.