You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This issue tracks a number of PRs that are submitted for C++26 that make a number of small individual changes, but put the standard into a state where it will be easier to make a large core clause reorganization in C++29.
The goal of these changes is to resolve the concerns in #2252 that tries to establish a good notion of build programs, phases of translation, and how a program runs in the front sections, before diving into the details of parsing C++. Any successful reorganization will likely involve moving material between [lex] and [basic], and possibly bringing relevant material forward from other clauses.
The following pull requests are deliberately part of separating concerns within within C++26 where possible, so that it will be easier to move whole clauses for C++29. Most of these changes are moving existing words around, so risk going stale as further edits are applied. They deliberately try to restrict themselves to moving existing words, leaving it to the C++29 edits to better integrate the text after any substantial reorganization.
[X] #7180 [lex.separate][module.unit] move definitions of program and translation unit (C++29, maybe)
This is a small change, redistributing a single paragraph but huge in the "meta" as it moves the definition of "program" to immediately precede its first use in the immediate first sentence in [lex]! Likewise, it moves the grammar for translation-unit out of [basic], where it is the only defined grammar but never used, to [module] which is the only consumer of this grammar term, and so into the same grammar section that needs it. In doing so two clauses are renamed (but not their stable labels) and this sets up the picture of the planned work for C++29.
(may reconsider for C++29)
If we are not prepared to do this change for C++26, it would be good to mark it for C++29 now. That applies to all of the following PRs too, most of which will hopefully be less controversial.
[x] #7351 [lex.separate] Redistribute second comment. (defer to P2996)
[x] #7192 [lex.phases] replace term 'input file' with 'source file' in phase 1 (current in discussing by Core). (write paper) #7346 [lex.pptoken] Do not use terms before they are defined (approved) #7336 [lex.header] Modernize text around header names (now simplified, to follow up with a Core issue after landing)
#6061 [basic.life] Move definition of "before" and "after" from last paragraph #7323 [basic.align] Move the Alignment clause adjacent to the Object model
#7122 [basic.pre] Defragment specification of names and entities
This change is important for setting up a higher coupling between names and linkage, which is one of the primary purposes of names, preceding the other main use --- name lookup --- as linkage will be part of the model that would move forward in C++29.
A second plan is to dissolve the [exception] clause into the rest of the standard, see #7317. There are two PRs for C++26 that would make that redistribution in C++29 simply a matter of moving whole subclauses:
[?] #7276 [except.uncaught] Tidy the specification for uncaught exceptions
This completes moving all the text describing the process of catching an in-flight exception into one clause.
Split PR into two commits, then land.
#7281 [except.terminate] Better describe the function terminate
This clarifies that the terminate function is now used for much more than exception handling, so that the whole subclause can move into a more appropriate subsection in C++29.
Finally, there is one PR to provide LaTeX macros identifying the first and last Core clauses, which will make any future reorganization of the major clauses simpler: #7191 [config.tex] Create and apply macros denoting first and last core chapters
It is harder to uniquely identify a first clause, as different ranges are used in different parts of the standard, but identifying the last Core clause is very helpful as it is both stable, and mostly likely to be changed in a future clause reorganization.
That should complete my own pre-planned work, others may have PRs they want to list below that they also feel would be helpful preparation.
The text was updated successfully, but these errors were encountered:
This issue tracks a number of PRs that are submitted for C++26 that make a number of small individual changes, but put the standard into a state where it will be easier to make a large core clause reorganization in C++29.
The goal of these changes is to resolve the concerns in #2252 that tries to establish a good notion of build programs, phases of translation, and how a program runs in the front sections, before diving into the details of parsing C++. Any successful reorganization will likely involve moving material between [lex] and [basic], and possibly bringing relevant material forward from other clauses.
The following pull requests are deliberately part of separating concerns within within C++26 where possible, so that it will be easier to move whole clauses for C++29. Most of these changes are moving existing words around, so risk going stale as further edits are applied. They deliberately try to restrict themselves to moving existing words, leaving it to the C++29 edits to better integrate the text after any substantial reorganization.
[X] #7180 [lex.separate][module.unit] move definitions of program and translation unit (C++29, maybe)
This is a small change, redistributing a single paragraph but huge in the "meta" as it moves the definition of "program" to immediately precede its first use in the immediate first sentence in [lex]! Likewise, it moves the grammar for translation-unit out of [basic], where it is the only defined grammar but never used, to [module] which is the only consumer of this grammar term, and so into the same grammar section that needs it. In doing so two clauses are renamed (but not their stable labels) and this sets up the picture of the planned work for C++29.
(may reconsider for C++29)
If we are not prepared to do this change for C++26, it would be good to mark it for C++29 now. That applies to all of the following PRs too, most of which will hopefully be less controversial.
[x] #7351 [lex.separate] Redistribute second comment. (defer to P2996)
[x] #7192 [lex.phases] replace term 'input file' with 'source file' in phase 1 (current in discussing by Core). (write paper)
#7346 [lex.pptoken] Do not use terms before they are defined (approved)#7336 [lex.header] Modernize text around header names (now simplified, to follow up with a Core issue after landing)#6061 [basic.life] Move definition of "before" and "after" from last paragraph#7323 [basic.align] Move the Alignment clause adjacent to the Object model#7122 [basic.pre] Defragment specification of names and entities
This change is important for setting up a higher coupling between names and linkage, which is one of the primary purposes of names, preceding the other main use --- name lookup --- as linkage will be part of the model that would move forward in C++29.
A second plan is to dissolve the [exception] clause into the rest of the standard, see #7317. There are two PRs for C++26 that would make that redistribution in C++29 simply a matter of moving whole subclauses:
[?] #7276 [except.uncaught] Tidy the specification for uncaught exceptions
This completes moving all the text describing the process of catching an in-flight exception into one clause.
Split PR into two commits, then land.
#7281 [except.terminate] Better describe the function terminateThis clarifies that the
terminate
function is now used for much more than exception handling, so that the whole subclause can move into a more appropriate subsection in C++29.Finally, there is one PR to provide LaTeX macros identifying the first and last Core clauses, which will make any future reorganization of the major clauses simpler:
#7191 [config.tex] Create and apply macros denoting first and last core chaptersIt is harder to uniquely identify a first clause, as different ranges are used in different parts of the standard, but identifying the last Core clause is very helpful as it is both stable, and mostly likely to be changed in a future clause reorganization.
That should complete my own pre-planned work, others may have PRs they want to list below that they also feel would be helpful preparation.
The text was updated successfully, but these errors were encountered: