C++ Logo


Advanced search

Re: [wg14/wg21 liaison] labels

From: Uecker, Martin <Martin.Uecker_at_[hidden]>
Date: Wed, 12 Aug 2020 13:55:25 +0000
Am Mittwoch, den 12.08.2020, 15:44 +0300 schrieb Ville Voutilainen:
> On Wed, 12 Aug 2020 at 15:29, Bjarne Stroustrup via Liaison
> <liaison_at_[hidden]> wrote:
> > > This is not the question, but it may explain a different
> > > view on the importance of this change.
> >
> > Possibly, but to me, "several people I talked to liked it" doesn't sound
> > like a solid argument for a change being important. That would be true
> > for both C and C++. I am still wondering how people could ever consider
> > this particular change sufficiently important to be worthwhile. Is there
> > a design rationale that I can consult?
> >
> > Not all people in the C++ committee appreciate C/C++ compatibility, but
> > I think that most do, and I do. I'm all for C/C++ compatibility, but it
> > should be a two-way street. When considering changes to C++, the
> > implications to C are considered, typically by people with deep and
> > long-term knowledge of C, incl. people who write C compilers.
> Allowing labels before declarations in C seems fine, that's a
> compatibility fix that C can make to be
> more compatible with C++. Introducing the allowance of labels at the
> end of a compound statement to C

The later is not really an additional change layered
on top of the first, but a natural consequence of
how the grammar in C is structured since C99 (when
it diverged from C++). In C it would be more
difficult to make the first change without also
doing the second, and - as you say yourself below -
disallowing it would be draconian.

> and then complaining that C++ is not compatible seems a bit rich,
> because it doesn't seem like the

Sorry, I was not complaining. Personally, I am
not really affected as I do not really use C++ much.

> cost/benefit ratio of that change in C is all that great.

WG14, which is much more conservative with respect
to changes in the language than WG21, obviously
thought differently.

In my opinion, this decision simply needs to be
respected by participants of the discussion.

Otherwise, I think there is not much
basis for a collaboration.

> Having said that, disallowing such labels seems.. ..draconian. It
> seems to be almost a "you diagnose this
> as a label at the end of a compound statement, so perhaps just drop
> the diagnostic and accept the program?".


> I don't see this change as anything really sinister or having wide
> impact, modulo implementation churn;
> it seems to be a miniature usability improvement. At the end of it, it becomes
> a question of whether it's worth doing when everybody can just add the
> null statements where required, and it's
> not hard to find why and how to do that.

It would be worth for the sake of compatibility.


Received on 2020-08-12 08:58:55