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].

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

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".

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.

Yes, the containers structure is weird.

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.

@jwakely , please have a look.

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.

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.

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

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.

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

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.

@jicama , renaming those two labels hardly counts as "clause restructuring", since it's not moving text around. @AlisdairM , do you refer to @jicama comment or something else?

@tkoeppe , we could have those label renames rather independently of anything else.

@jensmaurer I'm not even sure we should rename those labels. People are very familiar with them, and this could be pretty disruptive. What's the motivation here?

People are not familiar with those particular top-level labels. Why do we have [stmt.stmt] on the top level, and then [stmt.if] underneath? Same for [dcl.dcl]. Every time we need to pronounce these labels in CWG, people go another notch on becoming crazy.

The suggested library changes look great, thanks.

Side note: [dcl.dcl] and [stmt.stmt] are C++ tautonyms 😃 I'm not aware of any trinomial names, thankfully.

@AlisdairM , do you refer to @jicama comment or something else?

I was referring to your comment immediate preceding @jicama, about restructuring of specific Core clauses.

@jwakely thanks for the link --- an new term for my vocabulary :)

In our case, I don't think that it matters that we have tautonyms, but it is surprising to have multipart labels for a top level clause.

The core language changes likely need wording changes. Specific suggestions welcome, in a paper.

The reordering of #5315 (comment) is now done.

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.

Just to clarify for posterity: "locale" in the above refers to the entire clause [localization], not just its [locale] subclause.

I wonder whether <type_traits> should be placed in "Metaprogramming library", as some utilities in it are actually language-supporting.

@frederick-vs-ja , please consider this "for C++26" activity done and closed. Do we have a similar github issue for C++29 ?

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.