-
Notifications
You must be signed in to change notification settings - Fork 748
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
"Relevant clauses" in [basic.pre] is too vague #7127
Comments
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? |
In [intro.structure] we are already hardcoding |
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. |
Should we consider clause 5 [lex] a relevant clause too? |
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?"). |
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. |
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:
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.
The text was updated successfully, but these errors were encountered: