Date: Tue, 27 Apr 2021 20:36:49 +0200
Jens,
on Tue, 27 Apr 2021 13:50:02 +0200 you (Jens Maurer
<Jens.Maurer_at_[hidden]>) wrote:
> 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.)
Thanks!
So for a comma expression in a subscript we have that C++ is going
from "no restriction" to "deprecated" in C++20, and then, if the paper
is accepted in C++23, it would change semantics?
> > 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.
That would not even be my major argument. The first would be to repair
90% (wild guess) of the occurrence of bare comma expressions in that
position. The second would be compatibility with C++.
> ...
> > 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
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0305r1.html
I think this would be good to have in C, too.
> 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.
Ok, thanks again
Jāāā
on Tue, 27 Apr 2021 13:50:02 +0200 you (Jens Maurer
<Jens.Maurer_at_[hidden]>) wrote:
> 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.)
Thanks!
So for a comma expression in a subscript we have that C++ is going
from "no restriction" to "deprecated" in C++20, and then, if the paper
is accepted in C++23, it would change semantics?
> > 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.
That would not even be my major argument. The first would be to repair
90% (wild guess) of the occurrence of bare comma expressions in that
position. The second would be compatibility with C++.
> ...
> > 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
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0305r1.html
I think this would be good to have in C, too.
> 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.
Ok, thanks again
Jāāā
-- :: 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 ::
Received on 2021-04-27 13:36:55