Restructuring clauses for C++26

[jensmaurer]

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.

[JohelEGP]

Isn't "[charconv] Primitive numeric conversions" a good fit for Clause 26 "Numerics library"?

I think so, too. Currently, it's hard to find. It makes more sense than [text], as text can represent more than just numbers.

Maybe put all of locale, regex. std::format under I/O-ish (because locale-using)

I'm not sure. You can use std::format while avoiding the locale-using overloads. I'd lean more to moving it to [text].

[AlisdairM]

[meta] and [concepts] should be adjacent clauses, or [concepts] should become a subclass of [meta] adjacent to [type.traits].

[JohelEGP]

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]

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]

Yes, the containers structure is weird.

[jensmaurer]

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]

@jwakely , please have a look.

[AlisdairM]

We were also broadly in favour of moving <span> and <mdspan> from Container to Utilities, following the other vocabulary types such as tuple, optional, and any. However, there was also concern about too much churn in one standard, so it was agreed we defer that change to C++29.

[AlisdairM]

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]

There was no discussion about reordering Core clauses, such as by #2252. Is there time to revisit that in this cycle?

[jensmaurer]

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]

I would hope to rename [dcl.dcl] to just [dcl] and [stmt.stmt] to just [stmt].

[AlisdairM]

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.