Please stop trying to gaslight me.

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?

None of them IT IS NOT THERE!

If it was there it wouldn’t be WhatWG, it would have been some other standard you just made up.

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.