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

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