SG16 intends to produce a proposal for a vocabulary type to handle Unicode text and associated Unicode algorithms, tentatively named
std::text for C++ 23. No significant text handling facility is targeted for C++ 20.
std::text_view, an analogue of
char8_t, although useful for distinguishing Unicode string literals, does not guarantee well-formed UTF-8.
std::textwill not have the fat interface
std::textwill be independent of that.
std::textwill support allocators.
std::string, however there may be performance penalties.
std::textcan be null terminated cheaply, and this may be useful for OS APIs.
std::texta type parameter. That is, is it configurable for UTF-8, 16, 32, LE and BE, or, is there a single internal encoding which is an implementation detail.
std::text_viewmeet the requirements to be a view, as many operations may not be O(1) or even amortized O(1), although they may be asymptotic O(1).
operator==, or are comparisons only by specific named algorithms. There are trade-offs with usability vs surprising run-time costs.
Zach Laine is near code complete on his
text implementation and plans to submit it for Boost review soon.
Continue syndicating the idea that text is more complicated than programmers generally believe
Engage with LEWG and LWG for a paper to land directly into the DIS post C++ 2a. SG16 is concerned about having the bandwidth to do more than one core wording paper. If there is a good publicly available reasonably licensed implementation, the value of having a
std::experimental::text seems low.
I believe this accurately captures the current consensus of the group. I would like, with permission of the group, to send something very much like this in to the mailing, in order to appraise the community where we are, and in particular that C++20 std::text isn't happening.
Formatting is awful, paper is short enough that the TOC isn't needed, other comments and criticism welcome.