On Mon, Feb 8, 2021 at 12:51 PM Joseph Myers via Liaison <
liaison_at_[hidden]> wrote:

> On Mon, 8 Feb 2021, Jens Gustedt via Liaison 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.
>
> I think it's peculiar to do something just for assert and not for any
> other standard library macro (or, in C, almost any standard library
> function, as those could be defined as macros) that could be passed an
> argument involving a comma not inside parentheses (e.g. in a compound
> literal).
>
> The __VA_ARGS__ trick only works for macros with a single argument.
> Defining a new style of macro that takes balanced token sequences and
> ignores commas inside [] or {} would suffice for C, but it's less clear
> how that could work for C++.
>

Much of the functionality that C specifies as a function-like macro is
specified either don't exist or are specified as an overloaded function or
a function template in C++:

-- the macros in <math.h> (eg, fpclassify, isgreater, etc) become
overloaded functions in C++'s <math.h>
-- the macros in <tgmath.h> become overloaded functions in C++'s <math.h>
(C++ has no <tgmath.h> nor <complex.h>)
-- the CMPLX macros in <complex.h> don't exist in C++ (because <complex.h>
doesn't exist)

The following function-like macros exist in both C and C++:

assert, setjmp, offsetof, va_start, va_arg, va_copy, va_end, INTN_C,
UINTN_C, INTMAX_C, UINTMAX_C
ATOMIC_VAR_INIT, ATOMIC_FLAG_INIT (deprecated)

Of those, a __VA_ARGS__ solution would address all cases other than setjmp,
offsetof, va_start, va_arg, and va_copy, all of which are typically
implemented via compiler-specific magic in C++ implementations. So I think
a solution that addresses [] and {}, but not C++'s <>, plus some wording on
the C++ side that says that <> are treated properly by those 5
function-like macros, may be a workable solution.


> > (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:
>
> Constraint violations are generally problematic for macros; when arbitrary
> pp-token sequences can be passed as arguments, it's hard to ensure that
> the result of the expansion generates a constraint violation at the
> language level for every pp-token sequence not intended to be valid in
> that context, without having some language extension very specific to the
> exact constraint to be checked.
>
> --
> Joseph S. Myers
> joseph_at_[hidden]
> _______________________________________________
> Liaison mailing list
> Liaison_at_[hidden]
> Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/liaison
> Link to this post: http://lists.isocpp.org/liaison/2021/02/0295.php
>