On Wed, Oct 28, 2026, 14:27 Jonathan Wakely via SG16 <sg16_at_[hidden]>
wrote:

>
>
> On Wed, 28 Oct 2026 at 18:09, Tiago Freire <tmiguelf_at_[hidden]> wrote:
>
>> Please stop trying to gaslight me.
>>
>
> I'm not. I'm trying to have a discussion that doesn't work if you keep
> just firing emails off without reading my replies or the papers I've
> mentioned.
>
>
>>
>>
>> https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2026/p4246r0.html
>>
>> Section 13 Wording : *Header <transcode> synopsis [transcode.syn]*
>>
>>
>>
>> enum class codec {
>>
>> utf_8,
>>
>> replacement,
>>
>> x_user_defined,
>>
>> ibm866,
>>
>> iso_8859_2,
>>
>> iso_8859_3,
>>
>> iso_8859_4,
>>
>> iso_8859_5,
>>
>> iso_8859_6,
>>
>> iso_8859_7,
>>
>> iso_8859_8,
>>
>> iso_8859_8_i,
>>
>> iso_8859_10,
>>
>> iso_8859_13,
>>
>> iso_8859_14,
>>
>> iso_8859_15,
>>
>> iso_8859_16,
>>
>> koi8_r,
>>
>> koi8_u,
>>
>> macintosh,
>>
>> windows_874,
>>
>> windows_1250,
>>
>> windows_1251,
>>
>> windows_1252,
>>
>> windows_1253,
>>
>> windows_1254,
>>
>> windows_1255,
>>
>> windows_1256,
>>
>> windows_1257,
>>
>> windows_1258,
>>
>> x_mac_cyrillic,
>>
>> utf_16be,
>>
>> utf_16le,
>>
>> gbk,
>>
>> gb18030,
>>
>> big5,
>>
>> shift_jis,
>>
>> euc_jp,
>>
>> iso_2022_jp,
>>
>> euc_kr,
>>
>> };
>>
>>
>>
>>
>>
>> Please point which one of these codecs I would use to transcode to native
>> utf-16?
>>
>
> It's covered in the paper that you haven't read properly:
>
> https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2026/p4246r0.html#p2728-unicode-in-the-library
>
> P4246 proposes utilities to go to/from the program's native char32_t type
> to the external formats defined by the WhatWG spec.
>
> Do you remember in my last email how I mentioned P2728? I also mentioned
> it in the first email in this thread. And it's mentioned in P4246. That
> already proposes utilities that can go from char32_t to char16_t
>

In particular, the UTF views are natively typed. They can't express things
like big or little endian 16 or 32. You can wrap some byte swapping views
in, though.
But these are all byte oriented, which is on point for data interchange,
where there are external expectations that some bit of message is encoded
in network 32 bit, or instead on Windows native ordering. Very different
use case, and hopefully not terribly confusable. A small bit of overlap
where you have UTF-8 in a char buffer.


>
>>
>>
>> None of them IT IS NOT THERE!
>>
>
> Correct! I'm glad you've managed to read the paper well enough to get
> that. Do you remember my last email to you? It wasn'[t very long ago, and
> it wasn't a very long email. Not too many words to understand. You even
> quoted it below!
>
> It said "P2728. That proposes transcoding to/from all the Unicode
> encodings." Do you think you can figure out from those words how you might
> transcode to native UTF-16? Hint, it's also explained in P4246 at the link
> above.
>
>
>>
>>
>> If it was there it wouldn’t be WhatWG, it would have been some other
>> standard you just made up.
>>
>
> I didn't make up any standard, I said that P2728 provides the tools for
> going to/from UTF-16 in the program's native byte order, as char16_t code
> units. The proposal for WhatWG encoding doesn't do that, because it does
> something different.
>

And the Standard blesses the idea that charN_t is tied to UTF-N. The
closest we get to misuse of the types is saying that char32_t is a code
point as well as being UTF-32 encoding. But it's such a distinction without
a difference in the type representation it never really matters unless you
must worry about unmapped code points.


> Different things are different.
>
>
>
>>
>>
>>
>>
>>
>>
>>
>>
>> *From:* Jonathan Wakely <cxx_at_[hidden]>
>> *Sent:* Wednesday, October 28, 2026 18:20
>> *To:* Tiago Freire <tmiguelf_at_[hidden]>
>> *Cc:* Jens Maurer <jens.maurer_at_[hidden]>; sg16_at_[hidden]
>> *Subject:* Re: [isocpp-sg16] P4246R0 Transcoding Text Views and Ranges
>> for WhatWG and iconv
>>
>>
>>
>>
>>
>>
>>
>> On Wed, 28 Oct 2026 at 16:55, Tiago Freire <tmiguelf_at_[hidden]> wrote:
>>
>> Yes, I want more than WhatWG, and not just that.
>>
>>
>>
>> WG21 is not in the business of specifying character encodings, so we'd
>> need
>>
>> to refer to another standard for the details of each encoding.
>>
>> > Please name a particular encoding that isn't covered by WhatWG, and
>> point to the location of its specification.
>>
>>
>>
>> What are you talking about?
>>
>> WhatWG isn't an authority on ANY of those encodings.
>>
>>
>>
>> You know the iso-8859-XYZ is a standard setup by ISO. Utf-X is defined by
>> the Unicode standard, the windows-Z also have supporting documents setup by
>> Microsoft.
>>
>>
>>
>> The IANA list has references to the specs of the encoding defined by
>> their enumeration.
>>
>>
>>
>> Why are we still having this discussion?
>>
>>
>>
>> Because you keep digging yourself deeper?
>>
>>
>>
>>
>>
>> Please explain to me, and I would really like to know. How would the C++
>> standard and C++ developers benefit from being able to transcode windows_874,
>> be able to only transcode from Utf-16 big endian and little endia, but not
>> be able to transcode to and from NATIVE utf-16.
>>
>> What are we doing?
>>
>>
>>
>> Some of us are reading the paper that is the subject of the thread. Some
>> of us have also read the paper I named in the first sentence of the first
>> email of the thread: P2728. That proposes transcoding to/from all the
>> Unicode encodings.
>>
>>
>>
>> This proposal is different.
>>
>>
>>
> --
> SG16 mailing list
> SG16_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg16
> Link to this post: http://lists.isocpp.org/sg16/2026/10/4919.php
>