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)

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.

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.

Postponed to C++26.

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?).

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.

I really like this direction. But I agree with @jwakely. strings can remain their own section, that wouldn't be terrible. Otherwise they could fit in containers, but they are certainly orthogonal to unicode / text

Maybe we can talk about this again at a future editorial meeting. Last time I asked there wasn't a lot of interest, but we can certainly try this again for 26.

Another vote to move [strings] into [text] if we go in this direction, that the vocabulary type for much of [text] would be defined in [strings]. Also, basic_string is no longer the only container not defined in the [containers] clause, so it would no longer be surprising to find a container elsewhere.

Failing that, I would hope to at least see [strings] and [text] as adjacent clauses in any such reorganization.

Agree with moving [filesystem] to a top level clause as part of such a restructuring.

@tkoeppe Following discussion in Kona, [text.encoding] should also move there, But the rest of the organization outlined by Jens still looks good to me me.
Let me know how we can move forward with that.