On Wed, Aug 12, 2020 at 11:35 AM Uecker, Martin <
Martin.Uecker_at_[hidden]> wrote:

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

Because declaration-statement has additional semantics beyond statement.
Your wording change means that

{
  static X x;
}

no longer contains a declaration-statement, only a declaration, which
breaks (for example) [stmt.dcl] which gives additional semantics for
declaration-statements that don't apply for declarations in general.

You could instead change statement-seq-item to have a declaration-statement
production instead of a declaration production, but then the grammar is
poorly-factored, and would be better-factored if you moved the
declaration-statement productions of statement and statement-seq-item into
unlabeled-statement (which is the same end result that I was suggesting).

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

I don't think that having C++'s grammar factored the same way as C's
grammar should be a goal.

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_[hidden]
> > > Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/liaison
> > > Link to this post: http://lists.isocpp.org/liaison/2020/08/0135.php
> > >