C++ Logo


Advanced search

Re: [wg14/wg21 liaison] grammar cleanup

From: Jens Maurer <Jens.Maurer_at_[hidden]>
Date: Tue, 27 Apr 2021 13:50:02 +0200
On 27/04/2021 09.43, Jens Gustedt via Liaison wrote:
> The discussion about multi-dimensions array subscripts has brought to
> light that at least one incompatibility in the grammar between C and
> C++ has newly been created with C++20, namely that the subscript
> operator in C++ only accepts "assignment-expression" and not general
> "expression" as is still in C17.

This is not entirely accurate. C++20 reads
"A comma expression (7.6.20) appearing as the expr-or-braced-init-list
of a subscripting expression is deprecated; see D.4."

The grammar has not changed (yet), a comma expression appearing
here is just deprecated.

Paper https://wg21.link/p2128r5 proposes to change the grammar here
to (essentially) accept a list of assignment-expressions.
(Due to C++' braced-initializer feature, the actual grammar is a little
more complex.)

> If that would been done now, that
> would be a typical subject of discussion for this SG, I think.

Yes. It probably would be helpful if WG14 could form an opinion
whether they are good with changing "expression" to
"assignment-expression" inside [], opening a door for future
potential repurposing of the comma.

> The other recent incompatibility I am aware of is Martin Uecker's
> proposal in C23 for relaxing the places where labels may occur. As far
> as I understand there is effort on bringing that to C++, too.

The paper is here: https://wg21.link/p2324r0
tracked via https://github.com/cplusplus/papers/issues/1006
The paper is currently targeted at SG22 (only).

> Another field of concern could be selection and iteration statements
> where C++ has expanded the grammar by adding the possibility of
> declaring variables, similar as to `for`. I personally like that
> feature very much, but I wouldn't know if WG14 is ready for it, yet.
> In any case it would be good to know if these changes in C++ have
> introduced other changes in the grammar for these constructs, similar
> to what we have seen for the subscript operator.

The relevant paper was

P0305R1 Selection statements with initializer

I don't think there are further ripple effects on the grammar.

> I personally would find it a good thing if we could change all
> controlling expressions of selection and iteration statements to
> "conditional-expression". Yes, this would be change that would
> invalidate some existing code, but in a good way ;-) Using a comma
> operator or assignment then would be a hard error and it would be easy
> for programmers to update their code.

This is not something C++ has attempted to do, as far as I know.


Received on 2021-04-27 06:50:13