On Wed, 12 Aug 2020 at 17:55, Uecker, Martin
<Martin.Uecker_at_[hidden]> wrote:
>
> Am Mittwoch, den 12.08.2020, 17:39 +0300 schrieb Ville Voutilainen:
> > On Wed, 12 Aug 2020 at 17:32, Uecker, Martin
> > <Martin.Uecker_at_[hidden]> wrote:
> > > > I wonder what the definition of "decision simply needs to be
> > > > respected" is, and what room for collaboration
> > > > it leaves. Perhaps you could elaborate on that, so that I don't go
> > > > into hypotheticals?
> > >
> > > 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.
> >
> > Well, calling skepticism about the necessity and justification of the
> > change a rant suggests that we are fairly far from collaboration.
> > In case such skepticism on this mailing
> > list is considered inappropriate, I can certainly write papers
> > addressing WG14 or/and file NB comments on the drafts of the C standard.
>
> Papers would certainly be appreciated. NB comments, should
> we go down to this level?

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.

But hey, tongue-in-cheek: when I was told 12 years ago that I can't
just-like-that change what the lofty
WG21 had decided to do, I responded by becoming an active member of
WG21, and have been such an active
member for over a decade. So if this is a surreptitious invitation to
become an active member of WG14,
I might just entertain it. :)

> > > > > It would be worth for the sake of compatibility.
> > > >
> > > > It seems like we're talking about fixing an incompatibility that has
> > > > been recently introduced.
> > >
> > > ...while fixing a much bigger incompatibility.
> >
> > That fix is orthogonal to the introduced incompabitility, as far as I can see.
>
> Not really, I think. We would need an additional constraint
> to forbid labels at the end of compound block.

Well.. ..the one part of the change introduces somewhat similar
incompatibilities
as the other does, although with different impacts. As has been
already pointed out,
allowing labels before declaration statements brings a C++ facility
into C. Allowing
labels at the end of a compound statement introduces a new capability
into one-two languages.
It may be somewhat non-orthogonal specification-wise, but it sure
looks orthogonal and separable
otherwise.

Whether the impact of these separate changes is different, or whether
one just disappears in the noise
impact-wise, I'm not sure.