Restructuring clauses for C++23

[jensmaurer]

Sub-issues with discussion:
#2252 (basic, lex)
#3388 (utilities)
#3349 (atomics, thread, locale, regex, format)

Consensus items:

• Move [basic] before [lex]. Move [lex.separate] and [lex.phases] into [basic] just after [basic.pre].
• Move {class.free] to immediately before [class.nest]. (Class-specific de/allocation functions are member functions, after all.)
• Move [bit] to the end of [utilities].
• Move [stacktrace] to [diagnostics].
• Create a new top-level section "Memory management [mem]" immediately before [utilities] and move [memory], [smartptr], [memres], and [allocator.adaptor] there.
• Move [string.view] to immediately before [string.classes].
• Move [meta] to the top level, just before [utilities] (after [mem]), put integer sequences and ratio into it. Drop "compile-time" from subordinate headings. Eventual "reflection" would also go into [meta].
• Move [atomics] into [thread], after [thread.threads], before mutexes. Rename [thread] to "Concurrency support library".

[frederick-vs-ja]

Is "compile-time something" a good title? In the core specification, "translation" (which is more general than "compilation") is generally used.

[jensmaurer]

Fair question. I note we already have "compile-time" in the titles of two subsections of [utilities]. We also have "metaprogramming" in the title of [meta].

[jwakely]

[string.view] should be before [string.classes], because basic_string is defined in terms of basic_string_view, e.g. [string.copy], [string.find], [string.compare] etc.

It would be better if these were not forward references to something that hasn't been defined yet.

[tkoeppe]

Meeting notes:

See tick marks for approvals as is.

Accepted with modifications:

• Move [meta] to the top level, put integer sequences and ratio into it. Eventual "reflection" would also go into [meta].
• Move [atomics] to the end of after threads, before mutexes, not near the beginning.

Note re class.free: the subclause used to be bigger, but now it makes sense to move it.

No consensus for touching [cpp].

Re [charconv] and [format]: We will propose a larger reorganization here that creates a new "Text" Clause, containing formatting, charconv, locales, cctypes etc (everything other than cstring), and regex. This will be reproposed as a separate issue.

[jensmaurer]

Deliberations from the 2022-01-21 editorial meeting are reflected in the issue description at the top.

[StephanTLavavej]

Could the editors consider making [filesystems] a top-level clause? It is large (~50 pages) and in my opinion is both self-contained and very different from iostreams.

Aside: There is a typo in the issue description (may impact searching), [utilitites] should be [utilities].

[jwakely]

Yes I said the same thing about <filesystem> in the recent editorial telecon, but I can't remember why we didn't pursue the idea. Maybe one of the others remembers.

[jensmaurer]

• It fell through the cracks.
• It is still input/output in terms of "needs lots of operating system calls"
• Anything [input.output] is observable behavior per [intro.abstract] --- ah, that's actually not true, but that's a defect: [intro.abstract] p6.2 should be amended to talk about "stuff done to the filesystem, e.g. mkdir". Sounds like an LWG issue that needs CWG review. Let's rejoice.

[jensmaurer]

Removed [basic] / [lex] reshuffling from the C++23 plan.

[jwakely]

* Anything [input.output] is observable behavior per [intro.abstract] --- ah, that's actually not true, but that's a defect: [intro.abstract] p6.2 should be amended to talk about "stuff done to the filesystem, e.g. mkdir". Sounds like an LWG issue that needs CWG review. Let's rejoice.

Good point, I've submitted a new issue.