On 27/04/2021 20.36, Jens Gustedt wrote:
> 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?

Yes.

With C++23, a top-level comma inside [] would usually be
a hard error, unless the array-like type involved has a
suitable overloaded operator[]. At the beginning, there
will probably be approximately zero such types.
It will remain a hard error for uses of [] with C-style
arrays, because operator overloading is not possible on
built-in types.

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

There was an analysis of some high-profile code bases, which found
no accidental uses of the comma operator inside []:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1161r3.html#impact-on-existing-code-bases

However, I don't think the public code bases checked are representative
for predicting the potential accidental uses in less visible places.

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

So, WG14 should form an opinion whether they want this feature or not.

As a matter of FYI, beyond the more material changes enumerated above,
there are a number of lexing cleanups in the pipeline for C++23,
modeling the compiler-internal character set as Unicode and specifying
all non-printable characters involved with lexing (e.g. horizontal-tab)
using their Unicode short names for unambiguous clarity.

Aaron has them on the radar already (tagged with SG22):
https://github.com/cplusplus/papers/issues?q=is%3Aissue+is%3Aopen+label%3Asg22

Jens