Thank you all for all the hard work on this!

This is now the next PR in line to be merged. Could you kindly tell me if a) this is ready, and b) if there are any particularly noteworthy results from the review that need attention, and any follow-up issues that I should create to track problems that go beyond immediate editorial corrections to the proposed wording?

This is now the next PR in line to be merged. Could you kindly tell me if a) this is ready, and b) if there are any particularly noteworthy results from the review that need attention, and any follow-up issues that I should create to track problems that go beyond immediate editorial corrections to the proposed wording?

Well, as usual, another pair of eyes for the review could help.
However, @burblebee has done a detailed review, and I believe I've addressed all "small" issues that she noticed. Please read through the remaining open issues (those that are related to "outdated" diffs) and form your own opinion. There should be comment from me for each of them.
In short, this is sufficiently ready to be merged in my view. @burblebee is welcome to file an editorial issue for the remaining sore points.

So, this paper conflicts with Motions 1 and 3. I have done the following:

1. The new branch https://github.com/cplusplus/draft/tree/motions-2020-11-cwg-5-as_in_paper contains a squashed version of this PR, rebased on head, and always picking the changes from this PR (i.e. overwriting previous changes).

2. I also did a manual rebase and attempted to forward the previous changes; those appear in Rebase Motion 5 #4395. I split the diffs along which previous commit they attempt to forward.

If we can agree on that PR and commit it, then I would merge that result (probably by overwriting this branch with the new contents).

@tkoeppe @jensmaurer Should we send this back to CWG? There are many issues with the wording, and it would give them a chance to review the conflicts with the other motions.

@burblebee: this review has completely swamped me -- it's making GitHub fail to display the conversation page :-)

I think we should proceed with the paper in as close a form to the approved motion as we can. To this end, I created the rebase (see #4398), and I emailed CWG to ask for approval for those changes. The rebasing seems entirely doable, and should not by itself be an obstacle to applying this paper.

As for the open discussion, I think we should proceed through the usual channels: Anything that seems editorially improvable should become a GitHub issue, and any technical concerns should go to CWG. If you're unsure how to triage, keep it an editorial issue and tag it as "cwg" and we can ask CWG to re-triage it.

I will attempt to go through this conversation now and see if anything needs urgent attention, but a) I might well miss something, so please do call out and repeat something that you think really needs to be part of the initial commit, and b) the rebase already includes all the fix-ups that had been pushed to this branch (but I'll double-check If I missed anything new), so all of the resolved findings are going to be incorporated.

The paper comes after months of work, and it's probably not realistic to expect it to be entirely free of problems, so I would much rather have a new working draft that allows everyone to see the new wording in effect and iterate on that.

Thank you all again for the tremendous amount of work you've been doing on this!

@burblebee: this review has completely swamped me -- it's making GitHub fail to display the conversation page :-)

Yeah, it's gotten too big for github! Let's please split up giant motions like this in the future.

I think we should proceed with the paper in as close a form to the approved motion as we can. [...]

OK. And yes, this was quite a masterpiece - I'm in awe of Davis for taking this on. It was a beast to review - I can't imagine how hard it was to write!

I've listed below 2 problems that I have with this PR that I feel should be addressed before applying the motion:

1. Some fixes that Jens' made (and which I marked as resolved) may be missing from the motions-2020-11-cwg-5 branch after a forced update. For example, what happened to the following fix?
   In basic.tex around line 2221, I added a review comment in which I requested that a comma be added after "ignored" in the following change:

- In a lookup in which function names are not ignored
+ In a lookup for a qualified name whose lookup context is a class $C$
+ in which function names are not ignored

Jens said he "fixed" this, but I can't find that fix, nor can I find either the original or changed wording (above) that the review comment was added after.

The diff above and the conversation can be found in https://github.com/cplusplus/draft/pull/4379/files/8f1c9074cad73e2ca4e1756d929cebc3fa8e58fa if you load the changes for basic.tex. I pointed out another missing fix from that same commit; I expect there are many more.
What happened to these fixes?

2. If Jens' interpretation is correct, the paper uses ()s incorrectly, so it doesn't say what it thinks it's saying. For example in [class.qual]/p1, the paper has the wording:

Such a constructor name shall be used only in the /declarator-id/ of a (friend) declaration of a constructor or ...

Jens says this intended to say: "Such a constructor name shall be used only in the /declarator-id/ of a declaration (which could be a friend declaration) of a constructor or ..."
but what it's actually saying is: "Such a constructor name shall be used only in the /declarator-id/ of a declaration (which is a friend declaration) of a constructor or ..."
If Jens' interpretation is correct, then each case that uses ()s in this way should be rewritten to say the former or users will be very confused (as I was).

@burblebee: Thanks! Re (1), the comma is there, but after the footnote. See #4400 for post-merge cleanup. Can you check if there are any other presumed-fixed changes that are genuinely missing?

Re (2) that's definitely an issue we should solve in a separate commit after the merge, so let's track that in an issue. We'll make sure to resolve it for the new working draft, but it doesn't hold up the immediate merge.

@tkoeppe, I don't think the parens need to be resolved for the next working draft; we can fix that editorially in the next three months or so.
Note that the next mailing deadline is 2020-12-15, and we should strive to make that.

@burblebee: Thanks! Re (1), the comma is there, but after the footnote. See #4400 for post-merge cleanup. Can you check if there are any other presumed-fixed changes that are genuinely missing?

Doh! Yes, the comma is there, and the other fix that I thought was lost (and led me to believe many more were missing) is also there. Sorry. It would really help if we didn't squash fixes until just before merging.

Re (2) that's definitely an issue we should solve in a separate commit after the merge, so let's track that in an issue. We'll make sure to resolve it for the new working draft, but it doesn't hold up the immediate merge.

Sure, this is just the "working draft" after all :). Guess I'm trying too hard to have these papers make sense and mean what the author intended when added.

The [class.qual]/p1 "(friend)" is correct under the approved interpretation (which I didn't know was the only one here): that sort of lookup can happen only for friend declarations of constructors. Some other parentheticals "(x) y" mean "y, which might be x, but is still y"; I'm not aware of any that simply mean "x or y", but I haven't audited them.

I used the rebased change #4398 instead.