Date: Mon, 8 Feb 2021 20:51:27 +0000
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++.
> (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.
> 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++.
> (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]
Received on 2021-02-08 14:51:35