Date: Tue, 11 Aug 2020 09:43:19 -0700
On Tue, 11 Aug 2020, 09:16 Uecker, Martin, <
Martin.Uecker_at_[hidden]> wrote:
> Am Dienstag, den 11.08.2020, 09:04 -0700 schrieb Richard Smith:
> > On Mon, 10 Aug 2020, 23:37 Uecker, Martin via Liaison, <
> > liaison_at_[hidden]> 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?
> > >
> >
> > Superficially this seems like a fairly minor quality
> > of life improvement.
> >
> > But what about this:
> >
> > {
> > if (a)
> > label:
> > }
> >
> > Does the if-statement end after the label? Or is that still a parse
> error?
> > Neither option seems particularly nice to me.
>
> This is still not allowed. Why is this not nice?
>
It certainly seems like the better option. But it also makes a corner case
more complex: we go from the rule we've been teaching people for decades
that "you always need a statement after a label; use ';' if you don't have
one" to "you sometimes need a statement and sometimes don't". (You can
certainly argue that it's the if statement that needs a statement after it,
not the label, but however you describe it the rule seems to end up more
complex than before.)
Given that the value proposition is fairly weak to start with, especially
since C++ is on a path away from all constructs involving labels (with the
heavy discouragement of goto and with the upcoming addition of
pattern-matching expected to replace switch), the added complexity makes
this a very borderline change for me.
I think it's still worth asking the C++ committee if they want it. C++
implementations are presumably going to allow it regardless now it's part
of C2x, so we may as well standardize it even if we think use of labels is
on the way out in idiomatic C++.
The following code is still allowed:
>
> if (a)
> label: foo();
>
>
> Best,
> Martin
>
>
> > Another (old) difference between C is that in C++ you
> > > can use declarations everywhere where statements are
> > > allowed, which includes with iteration, control, and
> > > jump statements.
> > >
> > > if (1)
> > > int i;
> > >
> > > This does not make too much sense in the context
> > > of C, so I do not think we will adopt this.
> > >
> > > Best,
> > > Martin
> > > _______________________________________________
> > > Liaison mailing list
> > > Liaison_at_[hidden]
> > > Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/liaison
> > > Searchable archives: http://lists.isocpp.org/liaison/2020/08/index.php
> > >
Martin.Uecker_at_[hidden]> wrote:
> Am Dienstag, den 11.08.2020, 09:04 -0700 schrieb Richard Smith:
> > On Mon, 10 Aug 2020, 23:37 Uecker, Martin via Liaison, <
> > liaison_at_[hidden]> 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?
> > >
> >
> > Superficially this seems like a fairly minor quality
> > of life improvement.
> >
> > But what about this:
> >
> > {
> > if (a)
> > label:
> > }
> >
> > Does the if-statement end after the label? Or is that still a parse
> error?
> > Neither option seems particularly nice to me.
>
> This is still not allowed. Why is this not nice?
>
It certainly seems like the better option. But it also makes a corner case
more complex: we go from the rule we've been teaching people for decades
that "you always need a statement after a label; use ';' if you don't have
one" to "you sometimes need a statement and sometimes don't". (You can
certainly argue that it's the if statement that needs a statement after it,
not the label, but however you describe it the rule seems to end up more
complex than before.)
Given that the value proposition is fairly weak to start with, especially
since C++ is on a path away from all constructs involving labels (with the
heavy discouragement of goto and with the upcoming addition of
pattern-matching expected to replace switch), the added complexity makes
this a very borderline change for me.
I think it's still worth asking the C++ committee if they want it. C++
implementations are presumably going to allow it regardless now it's part
of C2x, so we may as well standardize it even if we think use of labels is
on the way out in idiomatic C++.
The following code is still allowed:
>
> if (a)
> label: foo();
>
>
> Best,
> Martin
>
>
> > Another (old) difference between C is that in C++ you
> > > can use declarations everywhere where statements are
> > > allowed, which includes with iteration, control, and
> > > jump statements.
> > >
> > > if (1)
> > > int i;
> > >
> > > This does not make too much sense in the context
> > > of C, so I do not think we will adopt this.
> > >
> > > Best,
> > > Martin
> > > _______________________________________________
> > > Liaison mailing list
> > > Liaison_at_[hidden]
> > > Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/liaison
> > > Searchable archives: http://lists.isocpp.org/liaison/2020/08/index.php
> > >
Received on 2020-08-11 11:46:57