On 7/27/2016 12:28 AM, Shachar Shemesh wrote:
> On 27/07/16 10:14, Walter Bright wrote:
>> Thank you. I'd prefer it to say something along the lines that it stops
>> execution at the assert(0) in an implementation-defined manner. This
>> leaves whether messages are printed or not, etc., up to the
>> implementation. I don't think the spec should require more than that
>> (for example, some uses may have no means to print an error message).
>
> I would ask that it at least be a "recommends". This message is muchu useful,
> and finding out it is not displayed in DMD release mode was a major disappointment.
>
> Updated proposed text:
> The expression assert(0) is a special case; it signifies code that should be
> unreachable. Either AssertError is thrown at runtime if reached or execution
> terminated. In the later case, it is recommended that the implementation print
> the assert message to stderr (or equivalent) before terminating. The
> optimization and code generation phases of the compilation may assume that any
> code after the assert(0) is unreachable.
>
> Shachar

Production of error messages is out of the purview of the core language specification, since it is highly dependent on the runtime environment, and the spec shouldn't get into Quality Of Implementation issues. Hence,

"The expression assert(0) is a special case; it signifies code that should be unreachable. If it is reached at runtime, either AssertError is thrown or execution is terminated in an implementation-defined manner. Any code after the assert(0) is considered unreachable."

On Wednesday, 27 July 2016 at 07:59:54 UTC, Walter Bright wrote:
> "The expression assert(0) is a special case; it signifies code that should be unreachable. If it is reached at runtime, either AssertError is thrown or execution is terminated in an implementation-defined manner. Any code after the assert(0) is considered unreachable."

Why that last phrase about "considered unreachable"? If "AssertError is thrown or execution is terminated" it implies that execution will not continue after assert(0).

Also "Any code after the assert(0)" is somewhat ambiguous about "after". Consider:

    if (random) goto twist;
    assert(0);
    twist: writeln("after assert(0)?!");

And also:

    try { assert(0); }
    catch (AssertError e) { writeln("after assert(0)?!"); }

On 7/27/2016 3:47 PM, qznc wrote:
> On Wednesday, 27 July 2016 at 07:59:54 UTC, Walter Bright wrote:
>> "The expression assert(0) is a special case; it signifies code that should be
>> unreachable. If it is reached at runtime, either AssertError is thrown or
>> execution is terminated in an implementation-defined manner. Any code after
>> the assert(0) is considered unreachable."
>
> Why that last phrase about "considered unreachable"? If "AssertError is thrown
> or execution is terminated" it implies that execution will not continue after
> assert(0).

Yeah, you're right.

On Wednesday, 27 July 2016 at 07:59:54 UTC, Walter Bright wrote:
> "The expression assert(0) is a special case; it signifies code that should be unreachable. If it is reached at runtime, either AssertError is thrown or execution is terminated in an implementation-defined manner. Any code after the assert(0) is considered unreachable."

Let me take a stab at it:

The expression assert(0) is a special case; it signifies that the code which follows it (in its scope of execution) should be unreachable. If execution reaches an assert(0) expression at runtime, either AssertError is thrown, or execution is terminated in an implementation-defined manner.

On Thursday, 28 July 2016 at 00:17:16 UTC, Walter Bright wrote:
> On 7/27/2016 3:47 PM, qznc wrote:
>> On Wednesday, 27 July 2016 at 07:59:54 UTC, Walter Bright wrote:
>>> "The expression assert(0) is a special case; it signifies code that should be
>>> unreachable. If it is reached at runtime, either AssertError is thrown or
>>> execution is terminated in an implementation-defined manner. Any code after
>>> the assert(0) is considered unreachable."
>>
>> Why that last phrase about "considered unreachable"? If "AssertError is thrown
>> or execution is terminated" it implies that execution will not continue after
>> assert(0).
>
> Yeah, you're right.

Another possibility would be "assert(0) never returns". This assumes that throwing an exception is not "returning", which is reasonable, since control flow does not leave via return statement.

On 07/26/2016 07:36 AM, ketmar via Digitalmars-d wrote:
> On Tuesday, 26 July 2016 at 14:28:48 UTC, Timon Gehr wrote:
>> "The expression assert(0) is a special case; it signifies that it is unreachable code. [...] The optimization and code generation phases of compilation may assume that it is unreachable code."
>
> so specs should be fixed. i bet everyone is using `assert(0);` to mark some "immediate error exit" cases.
>
FWIW, in that case I always use
assert (false, "...");
I try to never use integers for booleans.  But this may well be a common usage.

On Saturday, 30 July 2016 at 00:55:11 UTC, Charles Hixson wrote:
> FWIW, in that case I always use
> assert (false, "...");
> I try to never use integers for booleans.  But this may well be a common usage.

I suspect `assert(0)` is really `assert(<any logically-false constexpr>)`, so you should be fine. Both styles are used in Phobos.

On Sunday, July 31, 2016 21:45:25 Cauterite via Digitalmars-d wrote:
> On Saturday, 30 July 2016 at 00:55:11 UTC, Charles Hixson wrote:
> > FWIW, in that case I always use
> > assert (false, "...");
> > I try to never use integers for booleans.  But this may well be
> > a common usage.
>
> I suspect `assert(0)` is really `assert(<any logically-false
> constexpr>)`, so you should be fine. Both styles are used in
> Phobos.

assert(false) is definitely equivalent to assert(0) as is any other assertion where the compiler decides that the condition is known to be false at compile time. However, it's not like enum or static where the condition is forced to be evaluated at compile time. So, I don't know where it draws the line between determining the condition at compile time and letting that expression be evaluated at runtime. I wouldn't advise relying on it being compile time for stuff beyond 0 or false even though there are other cases where the compiler will decide that it knows that it's false at compile time.

- Jonathan M Davis