"Trip report: Summer ISO C++ standards meeting (Varna, Bulgaria)" by
Herb Sutter
https://herbsutter.com/2023/06/16/trip-report-summer-iso-c-standards-meeting-varna-bulgaria/

"ISO C++ is on a three-year development cycle, which includes a “feature
freeze” about one year before we ship and publish that edition of the
standard. For example, the feature freeze for C++23 was in early 2022."

Looks like a lot of new stuff.

Lynn

On 2023-06-19 11:54 PM, Lynn McGuire wrote:
> "Trip report: Summer ISO C++ standards meeting (Varna, Bulgaria)" by
> Herb Sutter
>
> https://herbsutter.com/2023/06/16/trip-report-summer-iso-c-standards-meeting-varna-bulgaria/
>
> "ISO C++ is on a three-year development cycle, which includes a “feature
> freeze” about one year before we ship and publish that edition of the
> standard. For example, the feature freeze for C++23 was in early 2022."
>
> Looks like a lot of new stuff.

I saw no mention of fixing the problem with C++ lacking Unicode support. :(

- Alf

On 6/19/2023 5:48 PM, Alf P. Steinbach wrote:
> On 2023-06-19 11:54 PM, Lynn McGuire wrote:
>> "Trip report: Summer ISO C++ standards meeting (Varna, Bulgaria)" by
>> Herb Sutter
>>
>> https://herbsutter.com/2023/06/16/trip-report-summer-iso-c-standards-meeting-varna-bulgaria/
>>
>> "ISO C++ is on a three-year development cycle, which includes a
>> “feature freeze” about one year before we ship and publish that
>> edition of the standard. For example, the feature freeze for C++23 was
>> in early 2022."
>>
>> Looks like a lot of new stuff.
>
> I saw no mention of fixing the problem with C++ lacking Unicode support. :(
>
>
> - Alf

I've slept since then. What areas of Unicode support do you want ?

Thanks,
Lynn

On 2023-06-20 2:28 AM, Lynn McGuire wrote:
> On 6/19/2023 5:48 PM, Alf P. Steinbach wrote:
>> On 2023-06-19 11:54 PM, Lynn McGuire wrote:
>>> "Trip report: Summer ISO C++ standards meeting (Varna, Bulgaria)" by
>>> Herb Sutter
>>>
>>> https://herbsutter.com/2023/06/16/trip-report-summer-iso-c-standards-meeting-varna-bulgaria/
>>>
>>> "ISO C++ is on a three-year development cycle, which includes a
>>> “feature freeze” about one year before we ship and publish that
>>> edition of the standard. For example, the feature freeze for C++23
>>> was in early 2022."
>>>
>>> Looks like a lot of new stuff.
>>
>> I saw no mention of fixing the problem with C++ lacking Unicode
>> support. :(
>>
>>
>> - Alf
>
> I've slept since then.  What areas of Unicode support do you want ?

A lot.

But starting with the stuff that everybody now has to implement on a DIY
basis:

* UTF-8 console INPUT (Boost NoWide provides that, but I remember when
Boost NoWide failed to remove ASCII carriage return characters from the
input, and perhaps it still does that, i.e. it was low quality).
* Iteration over code points in UTF-8 encoded text.
* Conversion UTF-8 -> code point values (i.e. UTF-32) and vice versa.
* Conversion UTF-8 -> UTF-16 (e.g. necessary to work around
std::filesystem::path issues/sabotage introduced in C++20).
* Uppercasing and lowercasing of e.g. `std::string`.

For OUTPUT the {fmt} library's `print` function, adopted in C++23,
provides Unicode text output where the device supports it, and that's
nice. The original library even takes care of handling the differences
between number of text bytes, number of resulting characters and width
of each character; I'm not sure if the standard library adoption does.
Essentially its (apparently undocumented) model is that specified format
width equals number of character cells in the console display, which is
convenient.

But that functionality is not exposed as something that can be reused,
e.g. there's no access to the character width functions that presumably
exist on the inside.

---

Since Usenet doesn't support graphics it's difficult to present an example.

But I'd like code like the following to be possible using only the
standard library,

and I'd like it to present a nice tidy table, i.e. not one where byte
counts and character widths play havoc with the presentation:

constexpr auto text = "Every 日本国 кошка loves blåbærsyltetøy!"sv;

void run()
{
// Just display the message.
print( "{}\n", text );

// Display one line for each code point with string index,
symbol and code point value,
// all nicely aligned vertically.
for( const u8::Cp_bytes_ref cp_bytes: u8::Cp_sequence_view(
text ) ) {
const auto index = cp_bytes.char_pointer() - text.data();
print( "{:2}: {:>6} {:>9}\n",
index, // Index in
string.
format( "‘{}’", cp_bytes.sv() ), // E.g. "‘日’".
unicode::to_spec( cp_bytes.as_number() ) // E.g.
"u65E5".
);
}
}

Modulo some namespaces this is working DIY code.

The C++ standard should not just provide all the support behind such
code, but should IMO also provide some way to avoid the verbosity of the
explicit type specification in the `for` loop. At least for UTF-8.

- Alf

On Tuesday, 20 June 2023 at 03:28:40 UTC+3, Lynn McGuire wrote:
> On 6/19/2023 5:48 PM, Alf P. Steinbach wrote:
> > On 2023-06-19 11:54 PM, Lynn McGuire wrote:
> >> "Trip report: Summer ISO C++ standards meeting (Varna, Bulgaria)" by
> >> Herb Sutter
> >>
> >> https://herbsutter.com/2023/06/16/trip-report-summer-iso-c-standards-meeting-varna-bulgaria/
> >>
> >> "ISO C++ is on a three-year development cycle, which includes a
> >> “feature freeze” about one year before we ship and publish that
> >> edition of the standard. For example, the feature freeze for C++23 was
> >> in early 2022."
> >>
> >> Looks like a lot of new stuff.
> >
> > I saw no mention of fixing the problem with C++ lacking Unicode support.. :(
> >
> >
> > - Alf
> I've slept since then. What areas of Unicode support do you want ?
>
C++ contains only obfuscation and denial about UTF-8 and even that is
few and far between.

* strings library contains some obfuscation classes/typedefs since C++20
like "std::pmr::u8string" or "std::u8string". Nothing uses nor converts to
from those garbage types;
* localization library had codecvt_*** junk that converted something but was
deprecated since C++17, right now it has nothing;
* rest of libraries like diagnostics, time, input/output, filesystem, regular
expressions etc. use neither obfuscation types from strings library nor
are integrated with junk of localization library.

IOW one can find nothing useful about UTF-8 in C++. As world is 97.9% of
UTF-8 then maybe it is worth to have anything about it in C++ too.