DIP 1006 is titled "Providing more selective control over contracts".

https://github.com/dlang/DIPs/blob/master/DIPs/DIP1006.md

All review-related feedback on and discussion of the DIP should occur in this thread. The review period will end at 11:59 PM ET on April 26 (3:59 AM GMT), or when I make a post declaring it complete.

At the end of Round 1, if further review is deemed necessary, the DIP will be scheduled for another round. Otherwise, it will be queued for the formal review and evaluation by the language authors.

Thanks in advance to all who participate.

Destroy!

On 12/04/2017 12:25 PM, Mike Parker wrote:
> DIP 1006 is titled "Providing more selective control over contracts".
>
> https://github.com/dlang/DIPs/blob/master/DIPs/DIP1006.md
>
> All review-related feedback on and discussion of the DIP should occur in
> this thread. The review period will end at 11:59 PM ET on April 26 (3:59
> AM GMT), or when I make a post declaring it complete.
>
> At the end of Round 1, if further review is deemed necessary, the DIP
> will be scheduled for another round. Otherwise, it will be queued for
> the formal review and evaluation by the language authors.
>
> Thanks in advance to all who participate.
>
> Destroy!

How exactly does this affect unittests?
From what I can see, in none mode unittests won't have any asserts, which is clearly a problem.

On Wednesday, 12 April 2017 at 11:32:37 UTC, rikki cattermole wrote:
> On 12/04/2017 12:25 PM, Mike Parker wrote:
>> DIP 1006 is titled "Providing more selective control over contracts".
>>
>> https://github.com/dlang/DIPs/blob/master/DIPs/DIP1006.md
>>
>> All review-related feedback on and discussion of the DIP should occur in
>> this thread. The review period will end at 11:59 PM ET on April 26 (3:59
>> AM GMT), or when I make a post declaring it complete.
>>
>> At the end of Round 1, if further review is deemed necessary, the DIP
>> will be scheduled for another round. Otherwise, it will be queued for
>> the formal review and evaluation by the language authors.
>>
>> Thanks in advance to all who participate.
>>
>> Destroy!
>
> How exactly does this affect unittests?
> From what I can see, in none mode unittests won't have any asserts, which is clearly a problem.

This is a -release style optimisation and would not be expected to be in dev/testing. Also unittest asserts call a different druntime function (IIRC) and therefore _should_ logically be under the control of -unittest and not affected by dip1006 OR be an invalid flag combination.

On 12/04/2017 12:48 PM, Nicholas Wilson wrote:
> On Wednesday, 12 April 2017 at 11:32:37 UTC, rikki cattermole wrote:
>> On 12/04/2017 12:25 PM, Mike Parker wrote:
>>> DIP 1006 is titled "Providing more selective control over contracts".
>>>
>>> https://github.com/dlang/DIPs/blob/master/DIPs/DIP1006.md
>>>
>>> All review-related feedback on and discussion of the DIP should occur in
>>> this thread. The review period will end at 11:59 PM ET on April 26 (3:59
>>> AM GMT), or when I make a post declaring it complete.
>>>
>>> At the end of Round 1, if further review is deemed necessary, the DIP
>>> will be scheduled for another round. Otherwise, it will be queued for
>>> the formal review and evaluation by the language authors.
>>>
>>> Thanks in advance to all who participate.
>>>
>>> Destroy!
>>
>> How exactly does this affect unittests?
>> From what I can see, in none mode unittests won't have any asserts,
>> which is clearly a problem.
>
> This is a -release style optimisation and would not be expected to be in
> dev/testing. Also unittest asserts call a different druntime function
> (IIRC) and therefore _should_ logically be under the control of
> -unittest and not affected by dip1006 OR be an invalid flag combination.

Please make it explicit that asserts are only in invariant and in/out blocks are affected. With a note about unittests, just to remove this possible incorrect implementation detail.

I am not happy with the args passed to the switch, but I can't think of an alternative names, so I am happy with how the DIP is including the above statements.

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
>
> All review-related feedback on and discussion of the DIP should occur in this thread. The review period will end at 11:59 PM ET on April 26 (3:59 AM GMT), or when I make a post declaring it complete.
>
> At the end of Round 1, if further review is deemed necessary, the DIP will be scheduled for another round. Otherwise, it will be queued for the formal review and evaluation by the language authors.
>
> Thanks in advance to all who participate.
>
> Destroy!

Is this supposed to affect release build, debug build or both of them?

On 12.04.2017 13:25, Mike Parker wrote:
> DIP 1006 is titled "Providing more selective control over contracts".
>
> https://github.com/dlang/DIPs/blob/master/DIPs/DIP1006.md
>
> All review-related feedback on and discussion of the DIP should occur in
> this thread. The review period will end at 11:59 PM ET on April 26 (3:59
> AM GMT), or when I make a post declaring it complete.
>
> At the end of Round 1, if further review is deemed necessary, the DIP
> will be scheduled for another round. Otherwise, it will be queued for
> the formal review and evaluation by the language authors.
>
> Thanks in advance to all who participate.
>
> Destroy!

The DIP should probably specify in detail how this interacts with -release.

I guess the difference between "-contracts=none -boundscheck=safeonly" and" -release" is that failing assertions are UB only with the latter?

What happens if I pass both -contracts=none and -release?

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
>
> All review-related feedback on and discussion of the DIP should occur in this thread. The review period will end at 11:59 PM ET on April 26 (3:59 AM GMT), or when I make a post declaring it complete.
>
> At the end of Round 1, if further review is deemed necessary, the DIP will be scheduled for another round. Otherwise, it will be queued for the formal review and evaluation by the language authors.
>
> Thanks in advance to all who participate.
>
> Destroy!

Why not

--disable-contracts=invariant
--disable-contracts=inout,invariants
--disable-contracts=asserts,inout

And so on?

On Wednesday, 12 April 2017 at 11:32:37 UTC, rikki cattermole wrote:
> On 12/04/2017 12:25 PM, Mike Parker wrote:
>> DIP 1006 is titled "Providing more selective control over contracts".
>>
>> https://github.com/dlang/DIPs/blob/master/DIPs/DIP1006.md
>>
>> All review-related feedback on and discussion of the DIP should occur in
>> this thread. The review period will end at 11:59 PM ET on April 26 (3:59
>> AM GMT), or when I make a post declaring it complete.
>>
>> At the end of Round 1, if further review is deemed necessary, the DIP
>> will be scheduled for another round. Otherwise, it will be queued for
>> the formal review and evaluation by the language authors.
>>
>> Thanks in advance to all who participate.
>>
>> Destroy!
>
> How exactly does this affect unittests?
> From what I can see, in none mode unittests won't have any asserts, which is clearly a problem.

Good point.
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.

On Wednesday, 12 April 2017 at 12:52:42 UTC, Timon Gehr wrote:
> On 12.04.2017 13:25, Mike Parker wrote:
>> DIP 1006 is titled "Providing more selective control over contracts".
>>
>> https://github.com/dlang/DIPs/blob/master/DIPs/DIP1006.md
>>
>> All review-related feedback on and discussion of the DIP should occur in
>> this thread. The review period will end at 11:59 PM ET on April 26 (3:59
>> AM GMT), or when I make a post declaring it complete.
>>
>> At the end of Round 1, if further review is deemed necessary, the DIP
>> will be scheduled for another round. Otherwise, it will be queued for
>> the formal review and evaluation by the language authors.
>>
>> Thanks in advance to all who participate.
>>
>> Destroy!
>
> The DIP should probably specify in detail how this interacts with -release.
>
> I guess the difference between "-contracts=none -boundscheck=safeonly" and" -release" is that failing assertions are UB only with the latter?
>
> What happens if I pass both -contracts=none and -release?

Addressing Daniel Kozak's question as well here:

Providing `-release` on the command line has the following effect:
- Disable invariants,
- Disable in and out,
- Disable assert,
- Disable switch error [1]

Which `-contract` just allows more control on.

TL;DR: It affects all build. It's a subset of `-release`, so passing `-contracts=whatever` and `-release` has the same effect as passing `-release`.

[1] Switch error: Compiler code here: https://github.com/dlang/dmd/blob/0158d32fcbbdda16b3f79e73f2f1f8c13afb9f6d/src/ddmd/statementsem.d#L2120-L2145
When a `switch has no `default,` in debug it'll insert a `default` which throws a `core.exception : SwitchError`, and in release the generated `default` will just be an `HLT` (same as `assert(0)`).

On Wednesday, 12 April 2017 at 13:45:08 UTC, Andrea Fontana wrote:
> 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
>>
>> All review-related feedback on and discussion of the DIP should occur in this thread. The review period will end at 11:59 PM ET on April 26 (3:59 AM GMT), or when I make a post declaring it complete.
>>
>> At the end of Round 1, if further review is deemed necessary, the DIP will be scheduled for another round. Otherwise, it will be queued for the formal review and evaluation by the language authors.
>>
>> Thanks in advance to all who participate.
>>
>> Destroy!
>
> Why not
>
> --disable-contracts=invariant
> --disable-contracts=inout,invariants
> --disable-contracts=asserts,inout
>
> And so on?

It was a conscious decision to provide something simple to use, over something which allowed more control (good old KISS). If a use case for it develop in the future, the addition will be trivial.