Counter example : <locale>

Good names,  yet unusable

On Fri, 12 Apr 2019 at 06:10, Tom Honermann <> wrote:
What is the motivation for having a namespace specific to text at all?  Ranges needed a separate namespace in order to provide constrained interfaces that were, in most but not all cases, functionally equivalent to the non-constrained interfaces.  New declarations were needed in order to avoid breaking backward compatibility.  I don't see a similar motivation for text as the existing text related names 1) aren't great names, and 2) are for interfaces that we explicitly don't want to replicate.  I think new interfaces deserve new names.  I think it is  also informative that none of the names proposed below recycle existing names in 'std'.


On 3/30/19 5:11 PM, Lyberta wrote:
Ranges has made a precedent that we can provide better versions of old
functions by putting them into a separate namespace. It is general
consensus that almost all current text related function are obsolete. We
should consider a namespace for new ones.

I think std::text fits this. This namespace would contain functions that
are modern and can properly support Unicode (and other encodings!).

There is also a precedent of my proposal and D1628 having separate
namespace specifically for Unicode. Generally speaking, Unicode is a
subset of text processing so in mathematical sense it would be obvious
to put unicode namespace as std::text::unicode but here I agree that it
is too much typing.

So I propose the following:

std::text for general purpose text algorithms (to be determined as we
haven't even nailed the Unicode yet, but consider std::text::to_upper,
std::unicode for Unicode classes and algorithms. Everything in std::text
should be able to work with classes from std::unicode.

Then we can add more encodings under std or maybe right into std::text
if they are too simple.

Theoretical examples:


SG16 Unicode mailing list

SG16 Unicode mailing list