On Fri, Dec 3, 2021 at 4:55 PM Jens Maurer via SG16 <sg16@lists.isocpp.org> wrote:
On 03/12/2021 22.03, Tom Honermann wrote:
> On 12/1/21 2:28 PM, Corentin Jabot wrote:

>> I think Jens is right. MSVC does handle Shift-JIS specifically but I'm not sure we can/should mandate something that work universally, the burden on implementation could be high)
>
> Are you suggesting that we should revisit the consensus for the proposed resolution for LWG3576 <https://cplusplus.github.io/LWG/issue3576> from our 2021-08-25 telecon <https://github.com/sg16-unicode/sg16-meetings#august-25th-2021>?

Reading https://cplusplus.github.io/LWG/issue3576
right now (I wasn't present in August, it  seems),
this says

"any codepoint of the literal encoding other than { or }"

This seems to be a category error: A literal encoding produces
code units (see [lex.string]), not code points.

One could certainly endeavor to reconstruct code points from
code units, but it appears some encodings don't really have
a code point space to start with.  For example, wide-EBCDIC
paired with some narrow EBCDIC shifts between the two, but
it seems there is no single "code point" space that would
contain values for characters from both sets.

I believe the numeric value of a wchar_t would serve as the "code point" space in such a case.
 

Jens
--
SG16 mailing list
SG16@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/sg16