On Wed, Feb 3, 2021 at 11:24 PM Hubert Tong <
hubert.reinterpretcast_at_[hidden]> wrote:

> On Wed, Feb 3, 2021 at 5:13 PM Corentin via SG16 <sg16_at_[hidden]>
> wrote:
>
>>
>>
>> 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)
>>
> 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.

Sorry.
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
>>
>>
>>>
>>> Jens
>>>
>>> --
>> SG16 mailing list
>> SG16_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/sg16
>>
>