[text] Create "Text processing library" clause

[jensmaurer]

This issue is further to #5124.

The proposal is to create a top-level clause entitled "Text processing library" [text] in the Working Draft at the current location of [localization] that contains the following, in order:

• [charconv]
• [localization]
• [format]
• [re]
• C library
  • [cctype.syn]
  • [cwctype.syn]
  • [cwchar.syn]
  • [cuchar.syn]
  • [c.mb.wcs]

About 90 pages in total.

[Mick235711]

After this change, [strings] will only have ~40 pages and be the third-to-smallest library clause (just above [concepts], [diagnostics]). Did string classes really fit in text formatting? At least they are tightly related.

I think probably either merge [strings] with [text] or at least move these two clauses together (I lean towards not merging but adjacent, since strings are fairly self-contained). Currently purposed [localization] position seems to be too far from [strings], I'd say... (But just personal opinion)

[jwakely]

Did string classes really fit in text formatting?

No. They are containers of characters, not necessarily text. I can have a std::string containing invalid UTF-8, for example.

[tahonermann]

No. They are containers of characters, not necessarily text. I can have a std::string containing invalid UTF-8, for example.

I don't find that a persuasive argument for separating strings and text. The string related features are clearly intended to hold and work with text despite the lack of invariants to ensure well-formedness with respect to any particular encoding. I imagine that if we introduce additional text related containers in the future that do have strong encoding associations, they will likewise eschew enforcement of well-formedness due to performance considerations. In those cases, we'll probably relegate violations to library UB. Error handling (or lack there of) doesn't strike me as a good basis for library separation.

That being said, I don't have strong opinions regarding this organization so long as it continues not to impact header or module naming.

[jensmaurer]

Postponed to C++26.

[tkoeppe]

Given that we'll only need to send the new draft in the March mailing, I wouldn't be entirely opposed to still doing this now, but we should feel unreservedly that we're making an improvement, without any caveats or regrets.

I'd be happy to hear alternative suggestions (e.g. how about merging strings and text), and also positions on the status quo (@tahonermann?).

[jensmaurer]

I'm ok with moving all of [strings] (~50 pages) into [text], with the idea that they are intended to represent text. This gets the total to ~140 pages, with plans to grow further (e.g. regex v2, encoding conversion facilities, possibly more from the scope of ICU).

However, I do like the general idea of having [text] cover everything text-related, even if that means we're heading for a fairly large clause.

We had suggestions to make [filesystem] top-level; this appears to be a reasonable idea, too, but seems not really urgent. Maybe future network facilities also fit under an input/output umbrella, or at least fit together with [filesystem] into a fresh clause.