Am Mittwoch, den 28.04.2021, 10:36 +0200 schrieb Jens Gustedt:
> Martin,
>
> on Wed, 28 Apr 2021 07:52:41 +0000 you ("Uecker, Martin"
> <Martin.Uecker_at_[hidden]ttingen.de>) wrote:
>
> > Am Dienstag, den 27.04.2021, 09:43 +0200 schrieb Jens Gustedt via
> > Liaison:
> > ...
> > > 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.
> >
> > I would also like such a feature and it seems simple and
> > unproblematic.
>
> Ok, thanks, and I agree with your assessment for the C standard
> itself. I am still struggling when I try to anticipate what WG14
> could
> be willing to accept. (But this is probably a good thing.)
>
> > > 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.
> > >
> > > 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.
> >
> > I agree, we should think about deprecating these.
>
> So you would more go the route of depreciation than fixing it
> directly
> in the grammar?

I would probably prefer changing it in the grammar, but is
this realistic?

Best,
Martin

> In any case, such a thing would be better done in sync with C++. C++
> still has "condition" there, which for the intersection with C
> translates to "expression".
>
> Any thoughts from WG21 on this?
>
>
> Thanks
> Jₑₙₛ
>