On Thursday, November 28, 2013 17:40:55 Dicebot wrote:
> I have quickly tested it and looks like asserts are not removed from unittest blocks in release builds, only from normal code. Which does not seem to be documented on dlang.org but was probably introduced exactly to prevent existing tests from breaking in release mode. I have just learned something new :)

Exactly. unittest block assertions are treated somewhat specially. They're always around with -unittest, but all the others (aside from the ones which can statically be determined to be false - e.g. assert(0)) get compiled out in -released. So, if you're relying on an assertion to go off outside of a - unittes block in -release, you're in big trouble.

- Jonathan M Davis

On Thursday, November 28, 2013 19:53:48 Dicebot wrote:
> On Thursday, 28 November 2013 at 18:26:15 UTC, Joseph Rushton
> 
> Wakeling wrote:
> > I think it may actually be a bug in whether -release implies
> > version(release).
> > Try out the attached code.  (r)dmd -release release.d produces
> > an executable
> > that still reports that release mode is disabled.
> 
> There is no pre-defined version(release) in D according to spec.

The closest you would get would be

version(assert) {}
else { /* release */ }

- Jonathan M Davis

On Thursday, 28 November 2013 at 19:01:40 UTC, Jonathan M Davis wrote:
> The closest you would get would be
>
> version(assert) {}
> else { /* release */ }
>
> - Jonathan M Davis

Which does not work if you also have "-unittest" ;)

On Thursday, November 28, 2013 18:28:55 Gary Willoughby wrote:
> On Thursday, 28 November 2013 at 17:22:20 UTC, Dicebot wrote:
> > I don't know what is the proper way to handle this but current situation is clearly worth a bugzilla entry. It is just weird.
> 
> Maybe this is intended behaviour to handle testing AssertErrors in unit tests? How else could you test them.

I wouldn't. I honestly don't think that testing contracts is an appropriate thing to do, much as I can see why you might want to do it. If you're passing something to a functon which violates that function's contract, then you're violating its contract, which is technically undefined behavior as far as DbC is concerned.

I think that testing that the correct exception is being thrown from a function makes sense, because in that case, it's something that the function is suppose to handle. But per DbC, a function should never have to deal with input which violates its contract and it's undefined behavior if it's given such input. So, you really need to make sure that you never give it incorrect input. The assertions in an in block are just insurance so that you can catch bugs when you screw it up.

But if you're absolutely determined to validate your contracts, I'd suggest simply creating another function which does the validation and then calling that from within the in block. e.g.

bool validateFoo(int i, int j)
{
    return i <= j;
}

auto foo(int i, int j)
in
{
    asser(validateFoo(i, j));
}
body
{
    ...
}

And using a validator function has the advantage that you can make it available to callers of your function if you want to so that they can validate the input.

Or if you want to, validateFoo could be purely for the contract and just assert rather than putting the assertion in the in block (though that's a _lot_ less efficient when unit testing, as thrown exceptions are very, very slow). But either way, by putting the actual validation code outside of the in block, you can test the validation code.

- Jonathan M Davis

On 28/11/13 20:08, Dicebot wrote:
> Which does not work if you also have "-unittest" ;)

Plus, assert statements in the main body of code (not just the unittests) are enabled with -release if -unittest is turned on, but in- and out-contracts are still stripped.  An oversight, perhaps?

I don't know how I came up with the idea that version(release) was one of the predefined version conditions.  I do think it has some use, though.  Feature request? :-)

On Thursday, November 28, 2013 20:08:34 Dicebot wrote:
> On Thursday, 28 November 2013 at 19:01:40 UTC, Jonathan M Davis
> 
> wrote:
> > The closest you would get would be
> > 
> > version(assert) {}
> > else { /* release */ }
> > 
> > - Jonathan M Davis
> 
> Which does not work if you also have "-unittest" ;)

Then you're out of luck for having a version block which is enabled with -release if -unittest is also being used.

- Jonathan M Davis

On 28/11/13 20:25, Joseph Rushton Wakeling wrote:
> assert statements in the main body of code (not just the unittests) are
> enabled with -release if -unittest is turned on, but in- and out-contracts are
> still stripped.

After consideration, I think that this is the real issue here: it's not a problem that -unittest preserves assert() statements, but it _is_ a problem that it doesn't preserve _all_ of them.

I've filed a bug report to this effect:
https://d.puremagic.com/issues/show_bug.cgi?id=11636