On Wednesday, 12 April 2017 at 15:02:49 UTC, Mathias Lang wrote:
> I would say that `-contracts=none` and `-unittest` should behave the same as `-release` and `-unittest`, and currently it only turns asserts on ( https://github.com/dlang/dmd/blob/ac3225a025b578d45ff39a40dda35006fb455a37/src/ddmd/mars.d#L1100-L1109 ).
> I'll add a note about it in the DIP.

As said above, asserts in unittests are different, so we could separate enabling asserts in unittests and in the rest of the program.

On Wednesday, 12 April 2017 at 11:25:09 UTC, Mike Parker wrote:
> DIP 1006 is titled "Providing more selective control over contracts".
>
> https://github.com/dlang/DIPs/blob/master/DIPs/DIP1006.md

Has come up a couple of times and it's a good idea to allow more control over which checks are enabled.
I find the suggested switch levels a bit counter-intuitive and would suggest

  -release=assert,in,out,invariant

to be the equivalent of the current

  -release

while allowing to enable any subset, e.g.

  -release=assert,in.

The effect of

  -release=assert -release=in

would be to enable both.

Using -release= also avoids any confusion about the interaction of -release and -contracts=.

On Tuesday, 21 November 2017 at 14:15:30 UTC, Martin Nowak wrote:
>> https://github.com/dlang/DIPs/blob/master/DIPs/DIP1006.md
>
> Has come up a couple of times and it's a good idea to allow more control over which checks are enabled.
> I find the suggested switch levels a bit counter-intuitive and would suggest
>
>   -release=assert,in,out,invariant
>
> to be the equivalent of the current
>
>   -release
>
> while allowing to enable any subset

I like the idea of specializing the meaning of the -release flag via optional arguments.

One suggestion: replace -release=assert with -release=body, so in the above, you would have:

    -release=body,in,out,invariant

... which has the nice intuitive property of specifying _which bits of code_ release criteria will be applied to.

In other words, -release=body would result in asserts being removed from function bodies _and only there_.  That would make clearer that we're not removing asserts from e.g. unittests (or indeed contracts or invariants).

On 26/11/2017 11:59 AM, Joseph Rushton Wakeling wrote:
> On Tuesday, 21 November 2017 at 14:15:30 UTC, Martin Nowak wrote:
>>> https://github.com/dlang/DIPs/blob/master/DIPs/DIP1006.md
>>
>> Has come up a couple of times and it's a good idea to allow more control over which checks are enabled.
>> I find the suggested switch levels a bit counter-intuitive and would suggest
>>
>>   -release=assert,in,out,invariant
>>
>> to be the equivalent of the current
>>
>>   -release
>>
>> while allowing to enable any subset
> 
> I like the idea of specializing the meaning of the -release flag via optional arguments.
> 
> One suggestion: replace -release=assert with -release=body, so in the above, you would have:
> 
>      -release=body,in,out,invariant
> 
> ... which has the nice intuitive property of specifying _which bits of code_ release criteria will be applied to.
> 
> In other words, -release=body would result in asserts being removed from function bodies _and only there_.  That would make clearer that we're not removing asserts from e.g. unittests (or indeed contracts or invariants).

Agreed that looks good +1

On Sunday, 26 November 2017 at 12:09:37 UTC, rikki cattermole wrote:
> On 26/11/2017 11:59 AM, Joseph Rushton Wakeling wrote:
>> One suggestion: replace -release=assert with -release=body, so in the above, you would have:
>> 
>>      -release=body,in,out,invariant
>> 
>> ... which has the nice intuitive property of specifying _which bits of code_ release criteria will be applied to.
>> 
>> In other words, -release=body would result in asserts being removed from function bodies _and only there_.  That would make clearer that we're not removing asserts from e.g. unittests (or indeed contracts or invariants).
>
> Agreed that looks good +1

What would be the appropriate way to follow up on that idea?  The last I saw DIP 1006 was undergoing formal review, but the end of that period seems to have passed with no further follow-up.

I could always write up an alternative DIP, but I don't know if that would be the most constructive way forward.

On 27/11/2017 7:20 PM, Joseph Rushton Wakeling wrote:
> On Sunday, 26 November 2017 at 12:09:37 UTC, rikki cattermole wrote:
>> On 26/11/2017 11:59 AM, Joseph Rushton Wakeling wrote:
>>> One suggestion: replace -release=assert with -release=body, so in the above, you would have:
>>>
>>>      -release=body,in,out,invariant
>>>
>>> ... which has the nice intuitive property of specifying _which bits of code_ release criteria will be applied to.
>>>
>>> In other words, -release=body would result in asserts being removed from function bodies _and only there_.  That would make clearer that we're not removing asserts from e.g. unittests (or indeed contracts or invariants).
>>
>> Agreed that looks good +1
> 
> What would be the appropriate way to follow up on that idea?  The last I saw DIP 1006 was undergoing formal review, but the end of that period seems to have passed with no further follow-up.
> 
> I could always write up an alternative DIP, but I don't know if that would be the most constructive way forward.

Contact Mike&Author of the DIP.

On Monday, 27 November 2017 at 19:20:53 UTC, Joseph Rushton Wakeling wrote:

>
> What would be the appropriate way to follow up on that idea?  The last I saw DIP 1006 was undergoing formal review, but the end of that period seems to have passed with no further follow-up.

Formal reviews have two stages. The first stage is just a courtesy to allow last minute feedback before I ship the DIP to Walter & Andrei. After I send it to them, I await their decision and then I report it here.

In this case, only the first stage was completed. It's in their hands and as soon as I receive a decision I'll report it here.

> I could always write up an alternative DIP, but I don't know if that would be the most constructive way forward.

I would say that's the thing to do, but it's probably best to wait until we get a decision on 1006.

On Wednesday, 12 April 2017 at 11:25:09 UTC, Mike Parker wrote:
> DIP 1006 is titled "Providing more selective control over contracts".

Possible implementation https://github.com/dlang/dmd/pull/7980 FYI

On Sunday, 26 November 2017 at 11:59:28 UTC, Joseph Rushton Wakeling wrote:
> One suggestion: replace -release=assert with -release=body, so in the above, you would have:
>
>     -release=body,in,out,invariant

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).

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.

On 4/12/2017 4:25 AM, Mike Parker wrote:
> DIP 1006 is titled "Providing more selective control over contracts".
> 
> https://github.com/dlang/DIPs/blob/master/DIPs/DIP1006.md


Currently, we have 3 switches that affect the asserts: `release`, `boundscheck`, and `unittest`. The documentation for these new additions is completely confusing. No mention is made of interactions with the latter two. No mention is made on what happens if more than one of these switches is used, or what if the same switch appears multiple times.

I'd like to see a chart enumerating all the behaviors influenced by these switches, the default behavior, and which switch settings do what.

Each switch, when applied, should specify what happens to each behavior:

1. turned on
2. turned off
3. not affected

and that the switches are applied in the order they appear on the command line.

The use of comma-separated arguments is something I've argued against for other switches. The use of `-release=in -release=out` should be fine and is less confusing/buggy to implement.

The idea that `-release=in` actually turns *off* `in` is completely topsy-turvy.

Ideally, the whole thing should be simplified to its fundamentals:

1. leave the old switches as they are
2. Add a new switch, let's say "check":

   -check     turn on all checks
   -check=on  turn on all checks
   -check=off turn off all checks
   -check=xxx turn on check xxx
   -check=yyy turn on check yyy

simple, easy to explain, easy to comprehend, easy to implement, easy to extend with new checks.