On Wed, Aug 12, 2020 at 9:17 AM Ville Voutilainen via Liaison <
liaison_at_[hidden]> wrote:

> 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.
>

If WG14 is interested in continuing with this change, then Ville is spot
on: we want someone to write an EWG paper. I'll treat such a paper with a
somewhat high priority as a form of "C compatibility bug" and will schedule
it in a EWG telecon relatively soon. It's a simple change and I hope we
don't spend much time on it.

Personally I don't particularly care for the change, but I don't want
divergence in simple things like this either.