Jonathan,

on Mon, 8 Feb 2021 09:59:21 +0000 you (Jonathan Wakely
<cxx_at_[hidden]>) wrote:

> 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.

yes, it seems that C++ has a bit more complicated rules for conversion
;-)

For C, most conversions don't distinguish the implicit and the
explicit case. (The only case were it makes a difference is if the
target type is a pointer, I think.)

> You'd need to use assert((bool)obj) or an equivalent explicit
> cast. Maybe that's acceptable,

for C it wouldn't be acceptable, I think, because that would impose a
lot of changes to user code. And I would not like if we would impose
that to the intersection of the two languages.

> 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).

A change in C wouldn't necessarily have an impact on C++, because it
seems that you are providing your own semantic formulation of it.

But I am not fixed to use the pseudo-function syntax in C, this is
just one of the possibilities of improvement in that area. In any
case, we should keep an eye on this.


Thanks
Jens

-- 
:: INRIA Nancy Grand Est ::: Camus ::::::: ICube/ICPS :::
:: ::::::::::::::: office Strasbourg : +33 368854536   ::
:: :::::::::::::::::::::: gsm France : +33 651400183   ::
:: ::::::::::::::: gsm international : +49 15737185122 ::
:: http://icube-icps.unistra.fr/index.php/Jens_Gustedt ::