How are you going to separate the implementation from the implementation details?

Those exact encodings are explicitly listed in the paper, some of them are not even encodings, that is what is intended to be adopted as suggested by the paper.

And how would you expect to implement a transcoding library with a single “codec” token without an intermediate encoding that can map to all of them?

It may work for the “WhatWG” set, not for the generic case.

From: Jonathan Wakely <cxx@kayari.org>
Sent: Wednesday, October 28, 2026 13:45
To: Tiago Freire <tmiguelf@hotmail.com>
Cc: Steve Downey <sdowney@gmail.com>; SG16 <sg16@lists.isocpp.org>
Subject: Re: [isocpp-sg16] P4246R0 Transcoding Text Views and Ranges for WhatWG and iconv

On Wed, 28 Oct 2026 at 12:37, Tiago Freire <tmiguelf@hotmail.com> wrote:

> Because nobody uses it for web pages (https://w3techs.com/technologies/overview/character_encoding) and email,

Yet!

> and because no encoding/decoding is needed to convert UTF-32 data to scalar values. So the entire encoding spec is unnecessary for UTF-32, it's a no-op.

I disagree. I don’t do web. I want to transcode to and from UTF-32, and it deserves to be a proper citizen with an enum to match if everybody else has one. If you are arguing that we only should use this for web, then that is fine, but then I would argue that Chromium already exists and it doesn’t need to added into the standard.

Let’s not forget what the WhatWG is. Which is a group of browser vendors deciding that the way their browsers work should the way everybody else’s browser should work, regardless of what other innovations the technology would allow. And I am not particularly comfortable endorsing what essentially amounts to corporate induced barnacles disguised as an “open web standard” into other standards that have absolutely nothing to do with the web other than “it can be used to make web apps”.

> Which IANA standard are you talking about?

The IANA standard for character set identification numbers. https://www.iana.org/assignments/character-sets

Yes I thought you were talking about that. It's not a standard describing how to do encoding and decoding, it's a registry of names and aliases. It refers to an RFC which says which characters are in (some of) those charsets, but it doesn't tell you how to do decoding and how to handle invalid sequences. Saying we should have that instead of P4246 is a category error, and you seem unaware of the fact we already have it.

If there is going to be an enum identifying the different encodings there is not a single doubt in my mind that that should be the IANA’s one and not WhatWG.

We already have that, please see all my other mails in this thread.

And if that ever was up to an open vote I would have no doubt which one would have majority support. Or do you doubt this?

We already voted it in. It's not the same as the proposal being discussed in this thread.

And yes, if we did that then the “WhatWG” implementation wouldn’t work. Which is another reason not to do it.

I have plenty of criticisms of P4246 but I don't see why it wouldn't work.

People may have other opinions on this, but for me this is a hard NO. No way!