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