This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of Open status.

### 3011. Requirements for `assert(E)` inconsistent with C

Section: 19.3 [assertions] Status: Open Submitter: Jonathan Wakely Opened: 2017-08-18 Last modified: 2018-08-20

Priority: 2

View other active issues in [assertions].

View all other issues in [assertions].

View all issues with Open status.

Discussion:

The C standard says that the expression in an `assert` must have a scalar type, and implies (or at least allows) that the condition is tested by comparison to zero. C++ says that the expression is a constant subexpression if it can be contextually converted to `bool`. Those ways to test the condition are not equivalent.

It's possible to have expressions that meet the C++ requirements for a constant subexpression, but fail to meet the C requirements, and so don't compile.

>     #include <stdlib.h>

>     // A toy implementation of assert:
>     #define assert(E) (void)(((E) != 0) || (abort(), 0))

>     struct X {
>       constexpr explicit operator bool() const { return true; }
>     };

>     constexpr bool f(const X& x) {
>       assert(x);
>       return true;
>     }

C++ says that `assert(x)` is a constant subexpression, but as it doesn't have scalar type it's not even a valid expression.

I think either 19.3.2 [cassert.syn] or 19.3.3 [assertions.assert] should repeat the requirement from C that E has scalar type, either normatively or in a note. We should also consider whether "contextually converted to `bool`" is the right condition, or if we should use comparison to zero instead.

[2017-11 Albuquerque Wednesday night issues processing]

Priority set to 2; status to Open

Jonathan is discussing this with WG14

[2018-08-20, Jonathan comments]

This was reported to WG14 as N2207.

Proposed resolution: