On Wed, Feb 3, 2021 at 11:04 PM Jens Maurer <Jens.Maurer_at_[hidden]> wrote:

> On 03/02/2021 00.09, Corentin wrote:
> >
> > On Tue, Feb 2, 2021 at 11:57 PM Victor Zverovich <
> victor.zverovich_at_[hidden] <mailto:victor.zverovich_at_[hidden]>> 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
> satisfied.
>
> 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)
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


>
> Jens
>
>