C++ Logo

liaison

Advanced search

Re: [wg14/wg21 liaison] labels

From: Uecker, Martin <Martin.Uecker_at_[hidden]>
Date: Wed, 12 Aug 2020 19:06:32 +0000
Am Mittwoch, den 12.08.2020, 11:53 -0700 schrieb Richard Smith:
> 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:

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

I see. Thank you. Actually, I meant to put a declaration-statement
into statement-seq-item instead of a declaration.
In C the former does not exist, so I forgot to make
this change.


Best,
Martin

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


Received on 2020-08-12 14:10:05