On Mon, 8 Feb 2021 at 09:33, Jens Gustedt via Liaison <
liaison_at_[hidden]> wrote:

> Hi,
> just to give the discussion on
>
> > P2264R0 (http://wg21.link/p2264r0) Make assert() macro user friendly
> > for C and C++
>
> a start. For me, the paper by itself is a no-brainer, `assert` should
> have been `...` from the beginning, for all the reason that are given
> in the paper.
>
> Just some side remarks for the WG14ners, it looks to me that the C
> text has some weaknesses and could be even more improved at the same
> time.
>
> (1) The current presentation has `scalar expression` in the syntax as
> if this were a syntax term (which it isn't), but then the text only
> talks about `expression`. I think this could be corrected to say
> just `expression` in the syntax.
>
> (2) Currently, not passing a scalar expression is only UB and not a
> constraint violation. This looks weird to me. Generally we could
> have a new constraint section that says something like:
>
> "The type of the expression shall have an implicit conversion to
> `bool`."
>
> and change the corresponding sub-phrase of the description to
>
> "..., if the converted /expression/ is `false`, the `assert` macro ..."
>
> Another possibility would be to give the pseudo-prototype for the
> macro as
>
> void assert(bool expression);
>
> which would imply all the above by the usual rules for calling
> prototypes.
>

N.B. I'm currently preparing a revision of
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2207.htm which proposes to
make assert work as expected for C++.

If it was a real function with the signature assert(bool) (or specified to
behave as per the usual rules for calling such a prototype) that wouldn't
necessarily work for all C++ cases. A C++ class with an explicit conversion
to bool can currently be used in assert(obj) if assert is defined like:

#define assert(X) ((X) ? ... : ...)

but if it was a real function with a bool parameter then assert(obj) would
fail to compile. You'd need to use assert((bool)obj) or an equivalent
explicit cast. Maybe that's acceptable, as it might be simpler for both C
and C++ developers to reason about something that behaves like an actual
function call, but any changes in that area should consider N2207 (or the
revision I hope to publish in the next week or two).