Tom Honermann wrote:
> std::cout << u8msg("In the month of ") <<
> std::chrono::August << "\n";
>
>
> This code doesn't work today, right?
>
> So we're talking about - hypothetically - making this code possible to
> write,
> in the year 2027, on z/OS systems.
>
> Are you under the impression that no one is developing C++ code for these
> systems today?

No.

There's still a difference between old and new code. Old code is already
written, so we have to keep it working.

New code hasn't yet been written so we can choose _what_ new code we
want to support in 2027.

We have a problem we want to solve (on z/OS), but what you suggest is
not the only possible solution.

For example, one alternative way forward is to move to a literal encoding
capable of representing all Unicode code points, such as UTF-EBCDIC. This
is backward compatible with the EBCDIC literal encoding currently used,
but would still work roughly in the manner a literal encoding of UTF-8
would on "normal" platforms. You would be able to insert ordinary literals
to std::cout, and you would also be able to insert u8 literals to std::cout,
and both will work and do the same thing.

Another alternative way forward is to use std::wcout instead:

std::wcout << u8msg("In the month of ") << std::chrono::August << "\n";

coupled with a similarly capable wide encoding. In 64 bit mode, wchar_t
is 32 bit, which can easily represent EBCDIC in the < 0x100 case, legacy
double byte in the < 0x10000 case, and the rest of Unicode, with enough
room to spare.

The advantage of using wcout over cout/UTF-EBCDIC is that we don't
need to touch the ordinary literal encoding. It can be fully incompatible
with UTF-8, and yet inserting a "literal" and a u8"literal" to wcout will
still do the same thing.

(Your Japanese example would even work with a 'normal' double byte
wchar_t, if I'm not mistaken.)