On 6/10/21 5:10 AM, Gennaro Prota via Std-Discussion wrote:
On Wed, Jun 9, 2021 at 5:50 PM Brian Bi via Std-Discussion
<std-discussion@lists.isocpp.org> wrote:
Can someone provide a link to the document that contains the revisions that the committee is recommending to implementation vendors?
I still think that yours is a natural and legitimate question, and that
there should be such a document.

Perhaps the document you have in mind is something like P2131R0.  I don't know if maintenance of that paper is planned.  I would not be surprised if such a paper contrasting C++20 and C++23 materializes once C++23 is approved.  I recognize that the lack of a "live" publicly available document is unfortunate, but implementors know where to find this information.

The "unlisted papers" section details papers that were accepted for C++20 as DRs and therefore intended to be retroactively applied to prior standards.  The "Defects, issues, bug fixes" section discusses this further.

Additional papers are regularly published that detail accepted issue resolutions and whether they were accepted as DRs.  This CWG link and this LWG link will redirect to the most recent versions of these papers.  The contents are not for the feint of heart.  These are detailed reference papers with considerable history.

This is not the wild west, but rather a collection of processes optimized for the few experts that absolutely require this information.  That isn't to say that better processes aren't possible or that they wouldn't produce more benefits, but change is disruptive and costly and therefore must be carefully managed.  Such progress tends to be slow in organizations that predominantly consist of volunteers.

Tom.


However, to clarify the situation a bit: Anthony Williams told me what
happened (see (a)) and gave a hint as to why the committee didn't
"bother" with such a document (see (b)).

(a) the committee changed some of the C++20 facilities in an
incompatible way, and recommended that implementors which haven't
shipped a C++20 implementation yet go straight for the C++23 version

(b) implementors always ship something that doesn't match any published
standard anyway, either because they make errors and because they
somehow "cherry pick" defect reports and apply them retroactively, more
or less as they see fit.

I don't find this situation normal, and consider it a bit of a wild
west. And I think it is exacerbated by the fact that there are way too
many defects in the standard (which should raise a bell on the process,
as it would in software development).

Anyway, this is the status quo, and I don't think that a "random person
from the Internet" would convince the committee or even the implementers
(which are about the same thing?) to work differently.

I'll only add that (a) and (b) are my rephrasing of Anthony's words, so
I apologize if I didn't report his thoughts accurately. And that, of
course, other committee members might have a different view on the issue
(I've often found that, if you ask 10 committee members about something,
you'll get 11 different answers).