On Wed, Feb 3, 2021 at 11:24 PM Hubert Tong <hubert.reinterpretcast@gmail.com> wrote:
On Wed, Feb 3, 2021 at 5:13 PM Corentin via SG16 <sg16@lists.isocpp.org> wrote:

On Wed, Feb 3, 2021 at 11:04 PM Jens Maurer <Jens.Maurer@gmx.net> wrote:
On 03/02/2021 00.09, Corentin wrote:
> On Tue, Feb 2, 2021 at 11:57 PM Victor Zverovich <victor.zverovich@gmail.com <mailto:victor.zverovich@gmail.com>> wrote:
>     > For the core language, I think we should
>     > simply replace "execution character set" with "literal encoding" (narrow and wide),
>     > because we never actually care about character sets, just about encoding
>     I would be very much in favor of this change. "Literal encoding" is exactly what this is and "execution character set" is just confusing. I also agree that it shouldn't be tied to locales in any way.
> I'd love feedback on the draft I posted earlier in this thread which does that, whenever you have time before the next deadline :)
> A slightly more recent draft is here https://isocpp.org/files/papers/D2297R0.pdf <https://isocpp.org/files/papers/D2297R0.pdf>

The change for wchar_t in [basic.fundamental] says that wchar_t
can now use UTF-16 (i.e. one or two code units per code point)
Previously, wchar_t needed to be >21 bits for full Unicode support,
otherwise "distinct codes for all members of [Unicode]" is not

That seems a drastic change; I'm not sure which parts of the
iostreams library depend on wchar_t not using multiple code units
per code point.

Also, it warrants an Annex C entry.

See earlier conversation in the thread, Hubert suggested that we could fix the core wording without necessarily fix the library (which is a whole different ball game, to the extent it might not be possible)
I didn't mean to say that accepting UTF-16 for wchar_t is something we should "just fix" at this time. My question about the availability of appropriate C library functions was meant to indicate that we need to work with the C committee on this.

I think I totally miss-interpreted 

> AFAICT, we can implement the wording improvement for the status quo of wchar_t without making it more difficult to handle the larger question of UTF-16, etc.

I kinda agree that we can side step that question :)
I'm afraid it will remained unanswered 
wchar_t is not conforming on windows (their implementation uses 16 bits), which seems problematic as they are the primary users of wchar_t)

I agree about the Annex C entry


SG16 mailing list