[DO NOT MERGE] Proposed Core reorganization for C++29 #7272
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
AlisdairM
force-pushed
the
FULL_CORE_REWORK
branch
5 times, most recently
from
ce857d9 to
9e4cfff
Compare
Per comment on issue cplusplus#5315. Thanks to Jonathan Wakely for the notion of tautonyms.
Oops. Clearly the section describing the diffs against C++23 was not present in C++23 itself.
…apters This PR should show no difference in the rendered document, but will make it much easier to refactor the Core clauses in the future --- just as we can refactor Library clauses today.
The current contents of [basic.pre] jump between specifying different things. This PR moves all the specification of names to the front, followed by the specification of entities. There are two main benefits: (1) the specification for when two names are the same is a list of 4 rules that correspond to the 4 things than can form a name --- the connection is much clearer when the paragraphs are adjacent and the list is sorted to the same order; (2) in this form, even though all the words are the same, the reordering and merging of paragraphs a fit on a single page. The very last paragraph was forced over a page-break in the original layout.
…on unit The definition of program at the top of [basic.link] should move to the front of [lex.separate] so that it is defined before its first usage, and also clarifies that the phases of translation produce. Similarly, move the definition of the grammar production translation-unit to the top of the first clause to actually use it, [module.unit]. Finally, retitle [basic.link] as just Linkage, rather than prgrams and linkage.
This PR purely moves existing words around, and does not create any new content. It would be the precursor to a larger change set that might integrate [cpp] into lex, or move it adjactent, and similarly move [modules] adjactent. This may be more significant than we want to land in C++26, but I offer it while time is still available, and as inspiration for the C++29 reorg otherwise.
The grammar for universal-character-name is oddly sandwiched into the middle of the subcluase talking about the different character sets used by the standard. To improve the flow, extract that grammar into its own subclause. In the extraction, I make two other clarifying changes. First, describe this new subclause as 'a way to name any element of the of the tranlation character set using just the basic character set' rather than simply 'a way to name other characters'. Secondly, remove the 'one of' in the grammar where there is only one option to choose.
Also, merge the sentence on where universal characters are prohibited into the sentence describing universal characters, to make clear that there is no contradiction between nominating a character, and how that character can be used.
This commit makes substantial changes to the organization of the Core clauses, without changing wording. Notably, [lex] is now titled as Program construction rather than Lexical conventions, as its contents are significatly more than mere conventions, and with the phases of translation detail how a program is constructed and built. [lex] itself is now more clearly modeled after the phases of translation for each of the level 2 subheadings, grouping the relevant specification for how to process each phases that needs more than the simple text in the phases themsevles. The whole Core sections are reorganized, promoting overload and exception handling above classes and templates. The idea is that overloading is relevant to understanding how functions are called, while functions are well specified before we get to classes and templates. Exception handling moves forward as the last control flow, which is relevant for functions before we get to defining classes. Classes still precede templates, as clearly we support both function and class templates. For neatness, we integrate the fix for tautonyms in stable labels. Finally, we try to disentagle some of the wording around basic definitions of names etc.
This commit completes the planned Core reorganization by merging the preprocessor properly into Program construction, placed consistently for phase 4 of translation. The subclauses of [cpp] are similarly reorganized to put the more primitive functionality first, and putting the module related text up front, consistent with the order of the grammar. We finally bring the prohibition on defining keywords as macros out of the library introduction and directly into the specification for keywords. This is around the limit of what can be achieved before rewriting text to further reduce duplication, and to make the distinction of preprocessor-identifiers and TU-identifiers clear.
This completes the large-scale reorganization to move the text corresponding to the phases of translation for constructing programs into the same clause. Names and linkage correspond closely to phase 8, while program execution is the essence of phase 9. The [basic] clause has been rearranged to reflect the new structure.
AlisdairM
force-pushed
the
FULL_CORE_REWORK
branch
from
9e4cfff to
66cf23b
Compare
|
Note that this PR introduces two new overfull hbox warning, which at least guarantees we cannot accidentally merge! The new warning arise as [dcl] becomes clause 10 rather than clause 9, and so cross-references are ever so slightly wider. |
|
As this is essentially a request-for-feedback for a direction for a C++29 core clause re-org, it would merit the C++29 milestone as it is not intended to land for C++26. However, I plan to close this PR after the editors meeting at Wrocław, so it may be too short lived for that to be worthwhile? |
wg21bot
added
the
needs rebase
|
This PR was created as a proof of concept, to help inform #7399. It has served its time as it will not be maintained and continue to fall further and further behind the |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR, a response to #2252, shows a vision for re-ordering the Core
clauses around program construction for C++26. This is based on the
working draft of 2024/09/29. The intent is to show direction, and
submit a series of incremental PRs if positively reviewed.
The most significant changes are:
This rework moves words and sections around but, other than introducing a couple
of introductory sentences, does not change any of the text itself. Further clarification
and simplification that does edit the text could usefully follow, especially looking to
clarify further the separation of preprocessor to translation unit grammar where the
same terms are overloaded.
In addition there are a variety of small edits, improving local clarity, but again,
only by moving existing words around and not redrafting.
Overall, I find this proposed structure very helpful, as I better understood a
number of parsing issues, mostly preprocessing issues that I did not always
realise were preprocessing, but cannot be sure how much of my new understanding
comes from being involved in making the transformation itself.