"Relevant clauses" in [basic.pre] is too vague

[tkoeppe]

ISO have pointed out that the note "This Clause does not cover concepts that affect only a single part of the language. Such concepts are discussed in the relevant Clauses." in [basic.pre] is too vague.

We could either remove the note, or change "relevant clauses" to something more specific:

• "subsequent clauses"
• "clause 7 through clause 15"

Thoughts?

The latter is perhaps what we mean, but a tiny bit harder to maintain long-term. But if we don't want to include the library in this consideration, then it seems preferable.

[Dani-Hub]

I thought that we are not supposed to say "clause 7 through clause 15" anymore. Shouldn't that alternative be expressed as "clause 7 to clause 15" instead?

[tkoeppe]

In [intro.structure] we are already hardcoding ref{lex} through \ref{cpp}, so maybe the maintenance effort here is tolerable, and we can say \ref{expr} through \ref{cpp} here.

[tkoeppe]

I thought that we are not supposed to say "clause 7 through clause 15" anymore. Shouldn't that alternative be expressed as "clause 7 to clause 15" instead?

No, that was "just a recommendation", and I said we'd rather keep "through". Apart from this being a change for change's sake, Walter made a good point that "to" is more ambiguous regarding whether the range is half-open or closed.

[AlisdairM]

Should we consider clause 5 [lex] a relevant clause too?

[AlisdairM]

Also consider #7191 although there seem to be multiple possible answers for the "first" clause.

[tkoeppe]

Also consider #7191 although there seem to be multiple possible answers for the "first" clause.

That's why I'm not too keen on that PR. It just adds more complexity and mental overhead for now ("is this the right kind of first?").

[AlisdairM]

I could live with simplifying that PR down to just the last clause, but that feels asymmetrical. Having the ability to easily change the last core clause seems useful, especially as I will be aiming to relocate [cpp] or its contents in a C++29 clause re-organization ;) Also, there is no contention for which the last core clause is, only variations on first.

Once we have a canonical "first" clause, we would also have the potential to consider and clean up the unintended variations but I deliberately left that consideration out of #7191 for a follow-up.

[eisenwave]

Labeling P2 because I guess by the standard of "ISO thinks this is too vague", it's an objective problem.

#7191 has been merged at this point, so I guess we could go with the second option now?