Repository navigation
Restructuring clauses for C++26 #5315
Description
See #2252 [basic] before [lex]
Maybe also move the preprocessor section near lex or merge both into a new "lexical processing" clause.
[basic] has some details that need to move later, e.g. allocation/deallocation function details should go to "Declarations".
Operator overloading [over.oper] should partially move to [expr] and to "Declarations".
Isn't "[charconv] Primitive numeric conversions" a good fit for Clause 26 "Numerics library"?
keep Utility types: pair, tuple, variant, optional, any, bitset under [utilities], but create a new grouping subclause called "data types".
Maybe put all of locale, regex. std::format under I/O-ish (because locale-using)
Create [text] clause; see #5226 for details.
Activity
JohelEGP commentedon Feb 24, 2022
I think so, too. Currently, it's hard to find. It makes more sense than [text], as text can represent more than just numbers.
I'm not sure. You can use
std::formatwhile avoiding the locale-using overloads. I'd lean more to moving it to [text].AlisdairM commentedon Mar 14, 2023
[meta] and [concepts] should be adjacent clauses, or [concepts] should become a subclass of [meta] adjacent to [type.traits].
JohelEGP commentedon Mar 14, 2023
I agree with making [concepts] a subclause. Not much point to a top-level [concepts] if new concepts are, rightfully, placed in more pertinent subclauses. Its title also needs to better reflect that "not all concepts are here!" Perhaps "basic concepts".
AlisdairM commentedon Mar 22, 2023
Is it time to move the container header synopses closer to where their contents are defined? E.g., [array.syn],[deque.syn],[forward.list.syn],[list.syn], and [vector.syn] are all adjacent at the top of the sequence containers subclause, [sequences], before we start on the definitions in [array] as a sibling node, and similarly for the associative containers, unordered containers, and container adapters. I don't think any other library clause collects header synopses in this way.
jwakely commentedon Mar 22, 2023
Yes, the containers structure is weird.
jensmaurer commentedon Jun 29, 2024
Consensus from 2024-06-28 editorial meeting:
Have a new "text" top-level clause with charconv, formt, text.encoding, re, locale and the C library facilities mentioned in #5226.
New order top-level clauses: Algorithms, Strings, Text, Numerics, Time, I/O
Move [execpol] to the end of algorithms.parallel.
Move debugging to end of diagnostics
Reorder container subclauses (sequential, associative, unordered, adapters) so that the header synopsis comes just before the first "class template X" heading that describes the content of the respective header.
Move type.index to support.rtti and extract its header subclause so that it becomes a sibling of type.index.
jensmaurer commentedon Jun 29, 2024
@jwakely , please have a look.
AlisdairM commentedon Jun 29, 2024
We were also broadly in favour of moving
<span>and<mdspan>from Container to Utilities, following the other vocabulary types such astuple,optional, andany. However, there was also concern about too much churn in one standard, so it was agreed we defer that change to C++29.AlisdairM commentedon Jun 29, 2024
We also spoke about finding a new top level title for the Metaprogramming Library so that we could incorporate Concepts and place it adjacent to Type Traits. However, we did not find an acceptable solution at this time. It is anticipated that the reflection library will slide into the Metaprogramming Library.
AlisdairM commentedon Jun 29, 2024
There was no discussion about reordering Core clauses, such as by #2252. Is there time to revisit that in this cycle?
jensmaurer commentedon Jun 29, 2024
The core language changes that have been contemplated are more involved than shuffling subclauses around, so would need CWG oversight. I don't see an urgent need to do something.
jicama commentedon Jul 1, 2024
I would hope to rename [dcl.dcl] to just [dcl] and [stmt.stmt] to just [stmt].
AlisdairM commentedon Jul 1, 2024
These core reorganisation changes were suggested and not discussed for
both C++20 and C++23. Assuming they are now out of scope for C++26,
when should we raise them for C++29.
While they are not my suggestion, they are a change I am very much in
favor of.
20 remaining items
[std] Create new top-level Clause [text], following [strings]
[text, re] Move [re] into [text]
[std] Create new top-level Clause [text], following [strings]
[text, re] Move [re] into [text]
[text, localization] Move [localization] into [text]
[charconv, format] Move [charconv], [format] to [text]
tkoeppe commentedon Oct 16, 2024
The reordering of #5315 (comment) is now done.
[text, c.strings] Move text-related parts of [c.strings] to [text]
tkoeppe commentedon Oct 16, 2024
Just to clarify for posterity: "locale" in the above refers to the entire clause [localization], not just its [locale] subclause.
frederick-vs-ja commentedon Oct 17, 2024
I wonder whether
<type_traits>should be placed in "Metaprogramming library", as some utilities in it are actually language-supporting.jensmaurer commentedon Oct 17, 2024
@frederick-vs-ja , please consider this "for C++26" activity done and closed. Do we have a similar github issue for C++29 ?
tkoeppe commentedon Oct 17, 2024
I don't think we have a concrete proposal yet for another major restructuring. The core wording things we've talked about don't affect top-level clauses I believe. We can open an issue once there's some concrete idea that we'd like to pursue.
As for
<type_traits>specifically, sure, one could go back and forth about this, but I don't see an urgent defect here. There are multiple pieces of library that have some magic core language interactions (e.g.start_lifetime_as,bit_cast), and I'm not sure we should move all of those into [support]. A large part of<type_traits>consists of pure library machinery (like the transformations), and surely those should not be in [support]. So, I think the status quo is fine. Feel free to bring a more elaborate rationale.[dcl.dcl][stmt.stmt] Remove tautonyms from top level stable labels
[dcl.dcl][stmt.stmt] Remove tautonyms from top level stable labels