Am Mittwoch, den 12.08.2020, 09:26 -0700 schrieb Richard Smith:
> On Wed, 12 Aug 2020, 04:26 Uecker, Martin via Liaison, <
> liaison_at_[hidden]> wrote:
>
> > Am Dienstag, den 11.08.2020, 17:29 +0200 schrieb Jens Maurer:
> > > On 11/08/2020 08.37, Uecker, Martin via Liaison wrote:
> > > >
> > > > Hi all,
> > > >
> > > > I recently proposed changes to the C grammar which got
> > > > voted into C2X by WG14 (N2508, also see N2496).
> > > >
> > > > This allows placing of labels everywhere in a compound
> > > > statement, even before declarations and at the end
> > > > of a block, which was not possible in C so far.
> > > >
> > > > Example:
> > > >
> > > > {
> > > > start:
> > > > int i;
> > > > mid:
> > > > int j;
> > > > end:
> > > > }
> > > >
> > > > It has been pointed out to me that while C++ allows
> > > > labels before declarations, it does not allow them
> > > > at the end of a compound statement.
> > > >
> > > > I plan to propose a change to C++ to make this
> > > > possible too and I wonder if you have any comments
> > > > or suggestions related to this?
> > >
> > > I'm lukewarm on this. Your example becomes valid C++
> > > by adding a ";" after the "end:".
> > >
> > > So, having the change does not materially alter the
> > > expressiveness of the common subset of C++ and C.
> >
> > It would enhance compatibility.
> >
> > > I'd like to see the wording change for C++ to understand
> > > whether it's likely low-cost overall to add this.
> >
> > Ok, no wording yet, but the suggested grammar change would
> > be as follows (omitting attributes for simplicity):
> >
> > 8.1(1) gets refactored from
> >
> > statement:
> > labeled-statement
> > expression-statement
> > compound-statement
> > selection-statement
> > iteration-statement
> > jump-statement
> > declaration-statement
> > try-block
> >
> > to the following:
> >
> > statement:
> > labeled-statement
> > unlabeled-statement
> > declaration-statement
> >
>
> The separation of declaration-statement here seems arbitrary (and incorrect
> without changes elsewhere, since we specify execution semantics for
> declaration-statements that don't apply to declarations in general, in
> particular registering atexit destructors for static locals).

I don't quite understand why wording changes would
be necessary. Can you explain?

At the moment declaration-statement is already
generated from statement. So I just thought
I keep it there. Another reason is that it is then
closer to the C grammar.

In principle, the other two options you mentioned
below would work equally well, of course.

Best,
Martin

> I would suggest you move declaration-statement into unlabeled-statement and
> remove declaration from statement-seq-item.
>
> Alternatively, a more isolated change: add an optional sequence of labels
> to the end of a compound statement.
>
> compound-statement:
> { statement-seq <ins>label-seq[opt]</ins> }
>
> unlabeled-statement:
> > expression-statement
> > compound-statement
> > selection-statement
> > iteration-statement
> > jump-statement
> > try-block
> >
> >
> >
> > 8.2(1) gets refactored from
> >
> > labeled-statement:
> > identifier : statement
> > case constant-expression : statement
> > default : statement
> >
> > to:
> >
> > labeled-statement:
> >   label statement
> >
> > label:
> >   identifier :
> >   case constant-expression :
> >   default :
> >
> >
> > In 8.4(1), we then do the actual
> > change which is changing
> >
> >
> > compound-statement:
> > statement-seq
> >
> > statement-seq:
> > labeled-statement
> > statement-seq statement
> >
> > to
> >
> > compound-statement:
> > statement-seq
> >
> > statement-seq:
> > statement-seq-item
> > statement-seq statement-seq-item
> >
> > statement-seq-item:
> > label
> > unlabeled-statement
> > declaration
> >
> >
> >
> > Best,
> > Martin
> >
> >
> >
> > _______________________________________________
> > Liaison mailing list
> > Liaison_at_lists.isocpp.org
> > Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/liaison
> > Link to this post: http://lists.isocpp.org/liaison/2020/08/0135.php
> >