Am Mittwoch, den 12.08.2020, 09:21 +0200 schrieb Bjarne Stroustrup via Liaison:
> On 8/11/2020 11:54 PM, Florian Weimer via Liaison wrote:
> > * Bjarne Stroustrup via Liaison:
> >
> > > What benefits was this supposed to give programmers?
> >
> > Labels at the end of blocks?
> >
> > The most common use is an end label in an outer loop, so that it's
> > possible to continue the loop from within a nested loop.
> >
> > for (int i = 0; i < n; ++i) {
> > for (int j = 0; j < m; ++j) {
> > if (exit_condition(i, j))
> > goto continue_outer;
> > }
> > continue_outer:
> > ;
> > }
>
>
> I consider adding a semicolon there a very minor inconvenience. *If* I
> considered it an improvement not to add the semicolon and wanted to
> change the rule that a label labels a statement, I'd ask myself

You are not programming in C I assume. Most C programmers I talked
to a very much in favor to this change, at so where almost all members
of WG14 which were present.

> Why hasn't anyone bothered for almost 50 years? this cannot be all that
> important even if I like it.

The change made to freely mix declarations and statements
in C was made 20 years ago - not 50 years.

At that point the conceptual difference to C++ in treating
declarations was introduced - not now.

> What confusions will emerge in the community? Anyone saying just
> something like "a label labels a statement" will cause confusion and/or
> attract corrections and discussions on the Web; all the teaching
> material from K&R1 onwards are no long completely correct and won't be
> brought up-to-date for decades.

This could be said about all changes to the language.
According to your logic, we need to freeze the language
from 50 years ago.

But, again, you missed the main point: The rule "a label labels
statement" is important to teach only because people otherwise
are confused because their programs often do not compile
because of missing null statements. So we need to teach them
to add these point-less null statements using this rule.

This issue goes away completely. I would say: Good riddance.
 
> When will all tool chains I rely on be completely updated? If I write a
> piece of code using the new rule, it won't compile on any compiler or
> tool that hasn't been updated.

This is true for all new features. Does C++ not introduce new
features?

> Major compilers will comply reasonably
> soon (and may, as Richard point out, quietly start accepting programs
> that are illegal C++ thus exporting the benefits and problems to C++) ,

Sorry, this is unfounded critisiscm. The change brings C much closer
to C++.

> third-party tools with smaller user communities may never upgrade. There
> are hundreds, probably thousands, of tools "out there" that rely on some
> sort of C or C++ parsing. Prudent coding standards would have to ban the
> new construct to avoids damaging usability.

But not any other new construct or change? Y


Best,
Martin