August 04, 2015
On 8/4/15 7:53 AM, Steven Schveighoffer wrote:

> Any assert(0) in druntime or phobos with a message printed is an error.
> It's compiled in release mode.
>
> I'll look through and find them, and rework them.

First stab: https://github.com/D-Programming-Language/druntime/pull/1337

-Steve

August 04, 2015
On 8/3/2015 8:37 PM, Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= <ola.fosheim.grostad+dlang@gmail.com> wrote:
> The input/environment/code distinction does not work very well.

Sure it does. If your user ever sees an assert failure message, your program has a bug in it. Keep that in mind when designing the code, and the distinction will become clear.

August 04, 2015
On 8/4/2015 4:53 AM, Steven Schveighoffer wrote:
> Any assert(0) in druntime or phobos with a message printed is an error. It's
> compiled in release mode.

When you're debugging phobos, you aren't compiling in release mode.

But I've also been of the opinion, not widely shared, that any programmer supplied messages in asserts are pointless.
August 04, 2015
On 8/4/2015 4:58 AM, Steven Schveighoffer wrote:
> The only answer I can think of is to write a message to stderr, and then
> assert(0) as meta suggested.

Print an error message and exit via abort() or whatever. No need to generate a halt - the program hasn't entered an unknown state.

August 04, 2015
On 8/4/2015 8:04 AM, Dicebot wrote:
> Recently we had quite a lengthy discussion at work regarding possible guidelines
> for using asserts, contracts and enforce (we have similar own implementation)
> that would actually allow using -release flag for release builds. And got to
> certain principles that I believe may work in practice (even though they violate
> DbC ideology). I will check if I can publish those here.

That's worthy of more than just a newsgroup post. How about an article or a wiki entry?
August 04, 2015
On Tuesday, 4 August 2015 at 20:23:53 UTC, Walter Bright wrote:
> On 8/4/2015 4:53 AM, Steven Schveighoffer wrote:
>> Any assert(0) in druntime or phobos with a message printed is an error. It's
>> compiled in release mode.
>
> When you're debugging phobos, you aren't compiling in release mode.
>
> But I've also been of the opinion, not widely shared, that any programmer supplied messages in asserts are pointless.

Would you be of the opinion that assert should be a statement rather than an expression ? unreadability in the middle of expressions, especially when evaluation order is not well defined, is close to impossible to get right.
August 04, 2015
On 8/4/15 4:23 PM, Walter Bright wrote:
> On 8/4/2015 4:53 AM, Steven Schveighoffer wrote:
>> Any assert(0) in druntime or phobos with a message printed is an
>> error. It's
>> compiled in release mode.
>
> When you're debugging phobos, you aren't compiling in release mode.

Unless you aren't debugging it, but an assert is still triggering. I want to stress, the bug that was found in core.time was environmental, and without the end user debugging it for us, we would never have known what this was, because the message wasn't printed.

I should say, any assert(0) with a message printed that is possible to trigger in release mode is an error. If you can ensure it's only possible to trigger when compiled in debug mode (or for unit tests), then assert(0, msg) is fine.

> But I've also been of the opinion, not widely shared, that any
> programmer supplied messages in asserts are pointless.

They can be helpful for context if it's not obvious what should have triggered the assert.

for example:

assert(x > y, "x: " ~ x.toString() ~ ", y: " ~ y.toString());

-Steve
August 04, 2015
On 8/4/15 4:43 PM, Steven Schveighoffer wrote:
> I should say, any assert(0) with a message printed that is possible to
> trigger in release mode is an error. If you can ensure it's only
> possible to trigger when compiled in debug mode (or for unit tests),
> then assert(0, msg) is fine.

In that vein, would it be possible to make this a warning? i.e. if you compile a file in -release mode, and the compiler encounters an assert(0, msg), it emits a warning?

-Steve
August 04, 2015
On Tuesday, 4 August 2015 at 20:48:52 UTC, Steven Schveighoffer wrote:
> On 8/4/15 4:43 PM, Steven Schveighoffer wrote:
>> I should say, any assert(0) with a message printed that is possible to
>> trigger in release mode is an error. If you can ensure it's only
>> possible to trigger when compiled in debug mode (or for unit tests),
>> then assert(0, msg) is fine.
>
> In that vein, would it be possible to make this a warning? i.e. if you compile a file in -release mode, and the compiler encounters an assert(0, msg), it emits a warning?

I fail to see why it's a problem if assert(0) has a message. It's exactly the same as any other assertion except that it stays even with -release, and you don't get the message then (whereas with a normal assertion, you wouldn't get anything). Not being able to have a message for assert(0) would be just as bad as not having a message for any other assertion. By arguing that assert(0) should only have a message in debug mode, you'd be arguing for something like

static if(assert)
    assert(0, msg);
else
    assert(0);

which is pointless IMHO. I can definitely see an argument that we should be printing out something before the HLT instruction in -release mode, but as it stands, it's part of the spec that assert(0) just becomes a HLT instruction and so there's no message, and I don't think that should be a surprise given that the fact that assert(0) becomes a HLT instruction with -release is the key difference between it and other assertions. You don't get a warning about assertions having messages either, and their messages don't show up with -release. Instead, you get undefined behavior if they would have failed.

- Jonathan M Davis
August 04, 2015
On 8/4/15 4:56 PM, Jonathan M Davis wrote:
> On Tuesday, 4 August 2015 at 20:48:52 UTC, Steven Schveighoffer wrote:
>> On 8/4/15 4:43 PM, Steven Schveighoffer wrote:
>>> I should say, any assert(0) with a message printed that is possible to
>>> trigger in release mode is an error. If you can ensure it's only
>>> possible to trigger when compiled in debug mode (or for unit tests),
>>> then assert(0, msg) is fine.
>>
>> In that vein, would it be possible to make this a warning? i.e. if you
>> compile a file in -release mode, and the compiler encounters an
>> assert(0, msg), it emits a warning?
>
> I fail to see why it's a problem if assert(0) has a message. It's
> exactly the same as any other assertion except that it stays even with
> -release, and you don't get the message then (whereas with a normal
> assertion, you wouldn't get anything).

Seeing an assert with a message gives the impression that you will see the message if you get there. I get that normal asserts may not even trigger. But the concept of "oh, if I see that message I know what happened" really goes out the window if you are never going to see it.

As I said earlier, any line in druntime that has an assert(0, msg) is a bug, because the message is never seen.

Doing the static if thing isn't the right answer either. The right answer is to choose one or the other (and by choosing to print a message, you could either throw an assert error directly, or print the message specifically and then assert(0) ).

So basically:

assert(0, msg);

becomes

printSomehow(msg);
assert(0);

With druntime it's difficult to actually print the message (and my PR is trying to fix that).

-Steve