On Wed, 12 Aug 2020 at 18:56, Uecker, Martin
<Martin.Uecker_at_[hidden]> wrote:
> > > > > Well, if WG14, as the ISO committee in charge for C, which
> > > > > is full of C experts (including implementors, users, tool
> > > > > makers, etc.), after careful discussion just made
> > > > > a decision to make a change to the C language (which
> > > > > is rare enough), it is completely inappropriate - in my
> > > > > humble opinion - if the first reaction from the C++ side
> > > > > is to rant about how unnecessary and unjustified this
> > > > > change was.
> > You tell me. If your expectation is that various commenters here will
> > just adopt a draft C change because WG14
> > decided to make it, and the expectation is that we can't challenge
> > that decision, then we have other
> > avenues of discussion at our disposal.
>
> I wonder how you get the impression. It was pointed out to me
> that there is a remaining C++ issue in the proposal, which
> was intended to improve compatibility (not exclusively).

See the quoted bit above. :)

> > member for over a decade. So if this is a surreptitious invitation to
> > become an active member of WG14,
> > I might just entertain it. :)
> Why not? If you have serious concerns about the label
> at the end of a statement, I would be happy to see
> a paper that fleshed out the argument.

WG21 is a rather time-consuming endeavor already.. I'll try to briefly
flesh out the concern here, with some rumination
bits:

- after reading all of this and pondering about it, I don't think this
change invalidates oodles of explanatory material.
K&R documentation etc. might well say that you can't put a label at
the end of a compound statement, and
if people program with that in mind, they continue to be fine.
Slightly newer documentation might well say
that you can't put a label before a declaration-statement, and if
people program with that in mind, they continue
to be fine. It seems plausible to me that it's a reasonably palatable
teaching effort to then say "but in C2x, you
can do those things".
- now then, compatibility. The concern here is, of course, that there
may appear widespread libraries that just plain
don't compile with legacy compilers, and it can be challenging to
update said compilers, for a plethora of reasons.
It can also be challenging to convince the library vendor to support
legacy compilers. This is, of course, not
a problem in any way specific to this change.
- continuing on that: well, this is a C2x change. Any reasonable
library would tell its users "I require C2x", and it
should tell it early and loudly. Requiring C2x might be done for other
reasons instead or in addition to this particular one,
so this change might not be any particular straw that breaks our camel.
- major compilers that support both C and C++ will probably have no
particular trouble supporting this change; it
is somewhat more puzzling what the picture is for various less-major C
compilers - I suppose there's a larger amount
of those than there are C++ compilers, but I have no particular data
on that, that's just guesswork.

So, all in all, the concerns seem.. ..somewhat hypothetical. They are
mostly a concern that a programming community
ends up adopting shiny new toys too fast, breaking themselves in the process.

While I continue to be somewhat unconvinced about the cost/benefit of
this change, I think it's a reasonable step to toss it over to WG21's
EWG for further discussion. I find it somewhat plausible to justify it
as bringing more regularity to both languages,
removing a limitation, even if it's a limitation that is not something
I expect a lot of programmers to suffer from, because
it seems quite easy to find the reason for the diagnostic your
compiler gives you today.