On Wednesday, 12 April 2017 at 15:37:14 UTC, Mathias Lang wrote:
> 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.

Well, it's not simple to use if it doesn't fulfil your use-case. ;-)

With that in mind, it would seem simpler overall to not make assumptions about use-cases, and just allow the user a free choice of what kinds of contract they disable:

    --disable-contracts=invariant,in,out,assert,all

(Yes, I'm intentionally suggesting allowing `--disable-contracts=in`, `--disable-contracts=out`, and `--disable-contracts=in,out`.)

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!

I have to ask the newbie question, just to make sure we're not missing anything obvious. Why can't we fix invariants so that they're pay-for-what-you-use? In other words, is there a way we can make sure _d_invariant is never called (or early-outs) for classes that don't use invariants?

On Wednesday, 12 April 2017 at 16:22:00 UTC, Lewis wrote:
>
> I have to ask the newbie question, just to make sure we're not missing anything obvious. Why can't we fix invariants so that they're pay-for-what-you-use? In other words, is there a way we can make sure _d_invariant is never called (or early-outs) for classes that don't use invariants?

There's no newbie question :)

Sadly it is not possible. Consider the following hierarchy:
```
class Mother : Object { public int i; public void myFunction () {} }
class Daughter1 : Mother { invariant () { assert(i != 0); } }
class Daughter2 : Mother {}
```

The `Mother` class needs to insert invariant checks at the beginning and the end of `myFunction` to account for the possibility of a derived class defining invariant (here `Daughter1`). However those checks are superfluous if no `invariant` is defined, as it's the case with `Daughter2`.
However the base class cannot know this in advance (because it might be in a library and already compiler, for example).

On Wed, Apr 12, 2017 at 11:25:09AM +0000, Mike Parker via Digitalmars-d 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!

Overall, I support the idea of this DIP.

However, as others have mentioned, it needs to make it clear whether/how `-contracts=assert` here interacts with unittests. According to the discussion, apparently a different druntime function is used for asserts in unittests? If so, this needs to be clearly stated in the DIP.


T

-- 
People demand freedom of speech to make up for the freedom of thought which they avoid. -- Soren Aabye Kierkegaard (1813-1855)

On 12.04.2017 17:16, Mathias Lang wrote:
>>
>
> 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,

Actually, (at least) asserts are turned into compiler hints (i.e. potential UB).


> - Disable switch error [1]
> ...

I have missed that one.

Note that it also implies -boundscheck=safeonly.

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

It's not a subset unless "disable" can mean "turn failures into undefined behaviour".

On Wednesday, 12 April 2017 at 11:25:09 UTC, Mike Parker wrote:
>
>
> 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.


Reminder: There's one week remaining.

On Wednesday, 19 April 2017 at 13:28:03 UTC, Mike Parker wrote:
> On Wednesday, 12 April 2017 at 11:25:09 UTC, Mike Parker wrote:
>>
>>
>> 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.
>
>
> Reminder: There's one week remaining.

Final reminder: The review period ends in a little over 24 hours.

On Wednesday, 12 April 2017 at 17:16:33 UTC, H. S. Teoh wrote:
> Overall, I support the idea of this DIP.
>
> However, as others have mentioned, it needs to make it clear whether/how `-contracts=assert` here interacts with unittests. According to the discussion, apparently a different druntime function is used for asserts in unittests? If so, this needs to be clearly stated in the DIP.

Agreed.

The simplest behavior I could imagine for this switch is "override everything else". That is, no matter which other switch is used (release, unittests), the -contracts switch has the final say on which tests are enabled and which are suppressed.

On Wednesday, 12 April 2017 at 11:25:09 UTC, Mike Parker wrote:
>
> 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.

The review period has ended. Thanks to everyone who provided feedback.

On 4/12/17 12:34 PM, Mathias Lang wrote:
> On Wednesday, 12 April 2017 at 16:22:00 UTC, Lewis wrote:
>>
>> I have to ask the newbie question, just to make sure we're not missing
>> anything obvious. Why can't we fix invariants so that they're
>> pay-for-what-you-use? In other words, is there a way we can make sure
>> _d_invariant is never called (or early-outs) for classes that don't
>> use invariants?
>
> There's no newbie question :)
>
> Sadly it is not possible. Consider the following hierarchy:
> ```
> class Mother : Object { public int i; public void myFunction () {} }
> class Daughter1 : Mother { invariant () { assert(i != 0); } }
> class Daughter2 : Mother {}
> ```
>
> The `Mother` class needs to insert invariant checks at the beginning and
> the end of `myFunction` to account for the possibility of a derived
> class defining invariant (here `Daughter1`). However those checks are
> superfluous if no `invariant` is defined, as it's the case with
> `Daughter2`.
> However the base class cannot know this in advance (because it might be
> in a library and already compiler, for example).

You can check the vtable address against the known Object.invariant address.

To explain further (no idea what the symbol names are, but you get the idea):

executeInvariant(Object o)
{
   static so = new Object; // has default invariant
   if((&so.__invariant).funcptr != &(so.__invariant).funcptr)
        // need to call invariant, not the default
	o.__invariant();
}

I'm sure the compiler can do this without any indirections or virtual calls.

Better yet, just put null in the Object.invariant vtable entry. Then it's really easy!

-Steve