Subject: Re: [SG16-Unicode] Namespaces
From: Steve Downey (sdowney_at_[hidden])
Date: 2019-03-30 17:25:34
I would like to standardise the encoding and decoding interfaces, however,
as long as the implementation is open to extension, I would be content to
only require the UTF forms, and what char and wchar_t encodings are
supported by default, for example just the "C" locale.
More concrete proposal underway.
On Sat, Mar 30, 2019, 17:24 Tony V E <tvaneerd_at_[hidden]> wrote:
> Do we want to standardize anything besides unicode?
> IMO, no. In fact, I'd only standardize UTF8.
> Sent from my BlackBerry portable Babbage Device
> Original Message
> From: Lyberta
> Sent: Saturday, March 30, 2019 5:12 PM
> To: unicode_at_[hidden]
> Subject: [SG16-Unicode] Namespaces
> 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 list run by email@example.com