Hi Ville,

Am Mittwoch, den 12.08.2020, 18:04 +0300 schrieb Ville Voutilainen:
> 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]ettingen.de> 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.

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

I brought this forward here with essentially no expectation
or demands, except to discuss the options with the C++ side.

But I do appologize for the term "rant".

I have to admit that I felt a bit "attacked" though.
(no worries, I am internet-proof and I am not going to
carry a grudge towards anyone)).

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

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.

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

Correct.

> It may be somewhat non-orthogonal specification-wise, but it sure
> looks orthogonal and separable otherwise.

In that sense it is separable: We could just add a constraint
to forbid it.

On the other hand, C++ could just allow it.

Or there remains a difference. The world would not end.


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

It is probably not even worth all the emails... ;-)

Best,
Martin