I’ve only been commenting on P4246R0 the whole time, I haven’t read P2728, my comments were not towards P2728.
My only comments were P4246R0 is bad, it does a whole lot of wrong, and we shouldn’t adopt WhatWG just because some organization calls it “a standard”.
And I was just defending that position. I’m pretty sure if you want to do something different that it wouldn’t be all that hard to make something better.
Are we on the same page on that?
From: Jonathan Wakely <cxx@kayari.org>
Sent: Wednesday, October 28, 2026 19:27
To: Tiago Freire <tmiguelf@hotmail.com>
Cc: Jens Maurer <jens.maurer@gmx.net>; sg16@lists.isocpp.org
Subject: Re: [isocpp-sg16] P4246R0 Transcoding Text Views and Ranges for WhatWG and iconv
On Wed, 28 Oct 2026 at 18:09, Tiago Freire <tmiguelf@hotmail.com> 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@kayari.org>
Sent: Wednesday, October 28, 2026 18:20
To: Tiago Freire <tmiguelf@hotmail.com>
Cc: Jens Maurer <jens.maurer@gmx.net>; sg16@lists.isocpp.org
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@hotmail.com> 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.