On 8/4/15 7:33 PM, Walter Bright wrote:
> On 8/4/2015 2:07 PM, Steven Schveighoffer wrote:
>> With druntime it's difficult to actually print the message
>
>      fprintf(stderr, "You left the headlights on.");
>      assert(0);

Going under the assumption that the program isn't fully "with it", I don't want to use such complicated libraries as stdio.

In any case, the PR I have does it with system calls only.

-Steve

On Tuesday, 4 August 2015 at 22:13:40 UTC, Steven Schveighoffer wrote:
> On 8/4/15 5:39 PM, Jonathan M Davis wrote:
>
>> I'm certainly not opposed to have a message be printed before the HLT
>> instruction with assert(0), but I don't at all agree that the fact that
>> the message is not seen in -release is a reason not to have a message.
>
> For instance:
>
> https://github.com/D-Programming-Language/druntime/blob/master/src/core/time.d#L2283
>
> This makes it seem like a message will be printed in the case where ticksPerSecond was 0. but in reality it simply throws a segfault.
>
> Whether this happens or not in debug mode is pretty much irrelevant -- druntime is used in release mode by the vast majority of all developers, and this passes unit tests for us. It's the whole impetus for this thread, because someone actually did find a case where it gets there.
>
> So why have a message with the clock name that failed? Why not just assert(0)? The only purpose I see for such a message is to trick the reviewer into accepting it (not that this was the intention of course) as being sufficiently explanatory when an error occurs.
>
> We should always review such code with the view that when it *doesn't* print the message, is the error sufficient to a user such that they know where to look. I find it hard to believe it's *ever* sufficient, if you needed to have a message in the first place.
>
> We can look at it this way -- if you need to add a message to an assert(0) for it to make sense, you should find a different way to communicate that.

It was never expected that a user to see any of those messages anyway. The idea was that if they failed, there was something seriously wrong, and the program needed to be killed. If the message prints when it fails, great. It's more explanatory that way, but it's a bonus (and one that you do get if druntime is build in debug mode). The purpose was to kill the program, because it was in an invalid state.

- Jonathan M Davis

On Wednesday, 5 August 2015 at 02:52:40 UTC, Jonathan M Davis wrote:
> On Tuesday, 4 August 2015 at 22:13:40 UTC, Steven Schveighoffer wrote:
>> On 8/4/15 5:39 PM, Jonathan M Davis wrote:
>>
>>> I'm certainly not opposed to have a message be printed before the HLT
>>> instruction with assert(0), but I don't at all agree that the fact that
>>> the message is not seen in -release is a reason not to have a message.
>>
>> For instance:
>>
>> https://github.com/D-Programming-Language/druntime/blob/master/src/core/time.d#L2283
>>
>> This makes it seem like a message will be printed in the case where ticksPerSecond was 0. but in reality it simply throws a segfault.
>>
>> Whether this happens or not in debug mode is pretty much irrelevant -- druntime is used in release mode by the vast majority of all developers, and this passes unit tests for us. It's the whole impetus for this thread, because someone actually did find a case where it gets there.
>>
>> So why have a message with the clock name that failed? Why not just assert(0)? The only purpose I see for such a message is to trick the reviewer into accepting it (not that this was the intention of course) as being sufficiently explanatory when an error occurs.
>>
>> We should always review such code with the view that when it *doesn't* print the message, is the error sufficient to a user such that they know where to look. I find it hard to believe it's *ever* sufficient, if you needed to have a message in the first place.
>>
>> We can look at it this way -- if you need to add a message to an assert(0) for it to make sense, you should find a different way to communicate that.
>
> It was never expected that a user to see any of those messages anyway. The idea was that if they failed, there was something seriously wrong, and the program needed to be killed. If the message prints when it fails, great. It's more explanatory that way, but it's a bonus (and one that you do get if druntime is build in debug mode). The purpose was to kill the program, because it was in an invalid state.

Maybe in this case, it would have made more sense to simply throw an Error rather than use assert(0), since it inadvertently ended up depending on the system's environment, even though it was supposed to be guaranteed to work (differences in kernel versions was not taken into account). And I assume that if we threw an Error, then we'd get a message.

- Jonathan M Davis

On Tuesday, 4 August 2015 at 20:40:47 UTC, deadalnix wrote:
> 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.

Ping ? Walter ?

On Tuesday, 4 August 2015 at 23:06:44 UTC, John Colvin wrote:
> I'm 90% on Walter's side here as he's right for the majority of common cases, but on the other hand there are plenty of situations where the boundary between code error and environment error get blurred.

Well, the principled difference is that asserts are program-specification-annotations and should not in any way affect execution within the code unit, and if it does it should happen as if it was detected by a hypothetical supervisor external to the program.

E.g. for a batch program terminate and have the calling context unwind any side-effects (as in a transaction), or for an interactive program to enter emergency mode, save state in a temporary file and try to recover after restart.

Asserts are reflecting system specifications (not code, or just applying to code).

If you want to take height for code errors you should use enforce or throw. It makes plenty of sense to assume that code have errors, and to recover from it, but using asserts does not assume that you have errors. It is just a way to add specification to the code for validation/documentation purposes.

I don't want those in release at all. I have way to many asserts for that.

So this goes much deeper than you and Walter suggest.

On 8/4/2015 8:26 PM, deadalnix wrote:
> On Tuesday, 4 August 2015 at 20:40:47 UTC, deadalnix wrote:
>> 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.
>
> Ping ? Walter ?
>

If you want it as its own statement, write it that way. I don't see a need to change the language, nor would the breakage it would cause be justified.

On Wednesday, 5 August 2015 at 05:51:32 UTC, Ola Fosheim Grøstad wrote:
> specification to the code for validation/documentation purposes.

Err... Verification, usually not validation.

On Monday, 3 August 2015 at 23:57:36 UTC, Steven Schveighoffer wrote:
> At the very least, assert(0, "message") should be a compiler error, the message is unused information.

Only if you compile in -release mode.  Without wanting to get into a bikeshedding debate, I think that flag name may be mislead: it's not about release vs. development, it's about the tradeoff you are making between speed and safety.

On Wednesday, 5 August 2015 at 08:09:49 UTC, Joseph Rushton Wakeling wrote:
> On Monday, 3 August 2015 at 23:57:36 UTC, Steven Schveighoffer wrote:
>> At the very least, assert(0, "message") should be a compiler error, the message is unused information.
>
> Only if you compile in -release mode.  Without wanting to get into a bikeshedding debate, I think that flag name may be mislead: it's not about release vs. development, it's about the tradeoff you are making between speed and safety.

That's arguably true, but historically, release builds are where you turn off assertions and turn on optimizations. So, it does pretty much what most folks would expect from a release build (though some folks might assume that it turns on optimizations as well, which it doesn't). Now, there are good reasons to leave assertions in in release builds, but then you're arguably just using your debug builds in production (probably because you don't need the efficiency gain and are too paranoid to risk turning the assertions off).

So, you have a good point, but really, -release does with assertions what's normally expected of release builds, so I don't think that it's actually misleading at all.

- Jonathan M Davis

On Wednesday, 5 August 2015 at 06:37:21 UTC, Walter Bright wrote:
> On 8/4/2015 8:26 PM, deadalnix wrote:
>> On Tuesday, 4 August 2015 at 20:40:47 UTC, deadalnix wrote:
>>> 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.
>>
>> Ping ? Walter ?
>>
>
> If you want it as its own statement, write it that way. I don't see a need to change the language, nor would the breakage it would cause be justified.

I suppose he's asking as maintainer of SDC.