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




>
>
> 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.

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.
>
>
>