C++ Logo


Advanced search

Re: [wg14/wg21 liaison] labels

From: Ville Voutilainen <ville.voutilainen_at_[hidden]>
Date: Wed, 12 Aug 2020 19:50:13 +0300
On Wed, 12 Aug 2020 at 19:37, Niall Douglas via Liaison
<liaison_at_[hidden]> wrote:
> Resorting to torpedoing stuff at NB, or threatening the same, well I
> find that disrespectful of the process.

Well, first of all, there's nothing disrespectful about talking about
the possibility of NB comments;
they are a part of the process. Second, there has been no suggestion
nor threat to "torpedo"
anything, the possibility of NB comments has merely been mentioned as
a reminder.
What those possible NB comments might say hasn't been decided even

> > 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.
> If WG21 wants to pick a fight with WG14, please let it be over something
> which really really matters. Not labels at end of compound statements,
> which almost everybody here has agreed is so inconsequential it's barely
> worth discussing, let alone fighting about.

Feedback about doubts on the merits of a proposal is not "picking a fight".
There are some indications in this discussion that some contributors
to it (continue
to) view the matter as just a heads-up about what WG14 will put into
the next C standard,
and WG21 might wish to (or perhaps should) follow suit (with a heavy
suggestion that
they can do that or do nothing, but there are no other alternatives).
That's not how C standardization works, nor is it how subsequent C++
standardization works.

> I'd also point out that WG14 did everything right here. They took a
> decision which affects C++ core language, they relayed it here to
> liaison for WG21's information, WG21 ought to have replied "this doesn't
> break anything in C++, so we're happy" and that's that.

Well, it does break compatibility between different C++ standards in a
yet another
area, so I fail to see what the rationale for your claim that it
doesn't break anything is.
That's a long-term deployment issue for the language at large, and some of us
can't just ignore such issues even if you may think such issues plain
don't exist here.

Received on 2020-08-12 11:53:48