Am Donnerstag, den 13.08.2020, 09:55 +0200 schrieb Jens Maurer:
> On 13/08/2020 09.07, Uecker, Martin wrote:
> >
> > Am Mittwoch, den 12.08.2020, 23:49 +0200 schrieb Jens Maurer:
> > > On 12/08/2020 20.34, Uecker, Martin 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_lists.isocpp.org> 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).
> > >
> > > Agreed. It also seems easier to me to simply introduce an
> > > optional
> > > sequence of labels at the end of a compound-statement, instead of
> > > a large-ish refactoring of the C++ grammar.
> >
> > I would not call it large. It would be two additional
> > minor self-contained changes to create explicit
> > productions for "label" and "unlabeled-statements".
>
> Plus a change in the definition of "compound-statement".
>
> > I see several advantages of the changes above over
> > adding something special just for labels at the end of
> > the block:
> >
> > - more similar structure to the C grammar
>
> I don't see this as a goal per se. The grammar is a
> means to an end, and C++ and C are sufficiently different
> that they may reasonable choose different grammar
> representations.

Well, yes and no. The whole point of the discussion
is about aligning the two languages. Then I think
it makes sense to also do this it at the
level of the formal grammar or even the wording
of the standard, to the extend this is easily
possible. Of course, if there a good reasons
for the formal grammar or wording to differ,
then this is OK.

> For example, if we do go the "unlabeled-statement" route,
> I'd still ask for "declaration-statement" to be part of
> "unlabeled-statement" for C++, instead of being separate
> inside compound-statement. Traditionally, a declaration
> has been "just another statement" in C++, even if that has
> possibly non-sensical fall-out in a few corner cases.
>
> Trying to make something like
>
> if (blah)
> int y;
>
> ill-formed in C++ is a much larger change than the question
> of labels.

Of course. But I still think that

if (blah)
  int y;

is the real corner case, because a declaration
really does not make any sense here, while

{
  ....
  a:
}

makes perfect sense for labels, because
there is no reason why jumping to the end of
a compound should not be possible.

(The rule that a label always goes with a
statement might make sense for assembler,
but is makes no sense for a high-level language
with control flow constructs for structured
programming.)


So from this point of view, I think a grammar
which makes the later case the natural one
and the former the exception is preferable
to a grammar that does the opposite.

> > - more symmetry: all labels inside compound statements
> > are treated equally, which makes a lot of sense to me.
> > Fundamentally, there is no difference and I think it
> > is good when the grammar reflects this.
>
> But labels on single (non-compound) statements appear to
> be treated differently with this change; that's the flip
> side of the coin.

True, but they are also different in some sense.
My personal preference would even be to deprecate

if (bla)
  x: foo();

and to allow labels only inside compound-statements.

The rationale being that it makes sense to jump
around in a sequence of statements as described
by a compound-statements, but jumping to a
individual statement following a control-flow
construct is always a bit confusing.

But it is useful for macro programming, so
WG14 decided not to deprecate this.

> > - Finally, with the production at the end of the
> > compound struct, the parser may occasionally
> > need to to backtrack out of a series of labels.
>
> The grammar as specified in the standard may be different
> from what any specific parser actually implements. For
> example, the -list and -seq constructs are presented in a
> left-recursive manner for C++, but I thought I'd heard some
> implementations prefer to parse them the other way round.

Sure, it is not a big deal.

> I also note that [stmt.select] p2 in C++ has a rewrite
> rule that says we're rewriting a single-substatement of
> an "if" as a compound-statement. With your proposed grammar
> change, we're not just moving a "statement" inside a
> "compound-statement", but we have to (notionally) re-parse
> this, because any labels now match different grammar
> productions.

Right. We need to take the label into account here.
We have to rewrite:

if (x)
  a: int i;

to

if (x) {
  a: int i;
}

or to

if (x)
 a: { int i; }


In fact, if we would go for the first variant, we
would - after rewriting - never have labels outside of
compound statements anymore.

We could then even eliminate labels as well as
declaration-statements from regular statements
and introduce a ctrl-sub-statement that
is always rewritten to a compound statement.
In this way, all the irregularity (both, with
respect to declarations and also labels) could be
dealt with in a single rewrite rule.

Best,
Martin


> > > In C++, we say in [stmt.goto]
> > > "The goto statement unconditionally transfers control to the
> > > statement labeled by the identifier."
> > >
> > > This is obviously not true for labels at the end of a compound-
> > > statement,
> > > because there is no statement that is labeled in that case.
> > >
> > > So, we need a wording change here.
> >
> > Yes, this is clear. We have wording to always
> > add an implied null statement to labels inside compound
> > statements.
>
> Great.
>
> Jens
>