llvm / llvm/llvm-project

[clang][docs] consider how DR papers are listed/ordered on status pages

Open
#193,844 1 comment 1 reaction 0 assignees View on GitHub
clang documentation
Dominant language
LLVM
Stars
40.5k
Forks
18.7k
PR merge metrics
PR metrics pending

Description

From discussion in #193141:

> > Because we track DRs on the DR status page, perhaps these papers should only be tracked as DRs?
>
> When there is a paper, we should track it, in the section of the standard where it is adopted. (especially when the paper is very much non trivial like P0588

That's effectively the status quo but I question whether that continues to make sense. As a counter-example, we do not list http://wg21.link/P1787 on the C++ status page and I think that's a good thing because there's almost no chance we could mark C++23 as complete if we tried to track it as a feature paper because it touches 60+ core issues. I don't think we would want a partial status on that paper to mean we only claim partial support for C++23, right?

_Originally posted by @AaronBallman in https://github.com/llvm/llvm-project/issues/193141#issuecomment-4297552278_

@cor3ntin noted:
> @AaronBallman I'm not even sure what we are talking about
> * There are core issues we should support as DR
> * There are core issue resolved through papers
> * There are core issues that CWG decided were design-y in nature and were later solved, or made irrelevant by a paper
> * There are papers approved as DR that do not solve core issues
> * There are papers approved as DR that solve multiple or many issues.
> * There are papers approved as DR that solve multiple or many issues and also change things that are not the subject of a core issue - which is the case for P0588.
>
>
> I don't think "well, we are never gonna implement all of that" is a good criterion for not listing papers.
>
> So yes, i think it makes sense to keep tracking papers, especially knowing that a paper often arise when core decides an issue is too complicated or impactful to be listed by the normal issue process.
>
> The functional consequences of P1787 are fairly minor - it was designed as a wording cleanup exercise, even though it does affect lookup in unusual cases (and it a lot of unrelated changes). (I do think we have a bunch of issues that have been or would be solved by implementing parts of P1787)
>
> However the consequences of not implementing P0588 is that our lambda implementation is not conforming and we have a bunch of user-reported issues because people keep having issue with our lambda implementation. Hiding that information is not helping anyone.

... and the discussion continued for some more. Feel free to edit this comment if more of the previous discussion should be reflected.

Contributor guide

Open the contributing guide

Research direction

Start by reading the discussion in #193141 and the linked comments, then compare how DR papers are currently listed on the C++ and DR status pages. Done means the project has a decided, documented policy for whether papers are listed and how they are ordered, reflected consistently on the relevant status pages.

Written by the indexing model from the issue text.

Assessment

Tech stack
cpp
Domain
documentation
Issue type
Documentation
Difficulty
5/5
Estimated time
Over a week
Activity status
Quiet
Clarity
Needs clarification
Newbie friendliness
30/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.