> 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
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.
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?
And yes, if we did that then the “WhatWG” implementation wouldn’t work. Which is another reason not to do it.

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


From: Jonathan Wakely <cxx_at_[hidden]>
Sent: Wednesday, October 28, 2026 12:53
To: Tiago Freire <tmiguelf_at_hotmail.com>
Cc: Steve Downey <sdowney_at_[hidden]>; SG16 <sg16_at_[hidden]>
Subject: Re: [isocpp-sg16] P4246R0 Transcoding Text Views and Ranges for WhatWG and iconv



On Wed, 28 Oct 2026 at 09:41, Tiago Freire <tmiguelf_at_[hidden]<mailto:tmiguelf_at_[hidden]>> wrote:
> Do you have reason to believe that the WhatWG spec doesn't cover a broad set of use cases?

Well, utf_32 seems to be missing from the proposal to begin with.

Because nobody uses it for web pages (https://w3techs.com/technologies/overview/character_encoding) and email, 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.

But I can also ask if there is any reason to believe that WhatWG is a good spec, if it is useful, or even relevant enough?
And I’m leaning towards a NO. At least IANA is a much more reputable standard.

Which IANA standard are you talking about?


So why should we adopt “WhatWG” over any other that someone my come up with?

It's a widely used standard, which is certainly better than creating our own set of encoding rules.

Or even why should we not just the (in my opinion) superior one setup by IANA?

Which one?




From: Jonathan Wakely <cxx_at_[hidden]<mailto:cxx_at_kayari.org>>
Sent: Wednesday, October 28, 2026 09:56
To: Tiago Freire <tmiguelf_at_[hidden]<mailto:tmiguelf_at_[hidden]>>
Cc: Steve Downey <sdowney_at_[hidden]<mailto:sdowney_at_gmail.com>>; SG16 <sg16_at_[hidden]<mailto:sg16_at_[hidden]>>
Subject: Re: [isocpp-sg16] P4246R0 Transcoding Text Views and Ranges for WhatWG and iconv


On Wed, 28 Oct 2026, 08:15 Tiago Freire, <tmiguelf_at_[hidden]<mailto:tmiguelf_at_[hidden]>> wrote:

> That is, though, what the Web platform specifies, in terrible detail. There will never be another legacy encoding added to it, and all of the mappings from labels to the identifiers are fully defined.

There hasn’t been another one “so far”.
If there is any lesson that the several “iso_8859_*” and “windows_*” should have taught is that people keep making up encodings (even if that is not necessarily a good idea) and there are very good human reasons for it, that may have slowed down but I don’t see that fully stopping any time in the future.

We have utf-8 now. If a new encoding gets created and gets used for a significant amount of content, then browsers and other applications probably *should* handle it.


And it doesn’t even cover a fraction of https://www.iana.org/assignments/character-sets.
Yes. But most of those are even more legacy than the legacy ones in the WhatWG spec.


And “utf_16be” and “utf_16le” are not even encodings, but an artifact endianness in different systems.
The argument here is that people do a lot more C++ projects than just the chromium browser, and if we are going to adopt a transcoding into the standard we should make an effort to have it useful for a broad set of use cases.

Do you have reason to believe that the WhatWG spec doesn't cover a broad set of use cases?



But there is also the converse argument, I couldn’t care less about “windows_874” (or the rest of the bunch) when I can just use utf-8, and I think we should spend exactly 0 time from the committee or library implementers in order to support it. They should get their well-deserved “we are not going to support it”, and just let it go extinct and thus stop being a problem. We don’t need that bloat.

It does seem like something that can be a standalone library outside the standard. One implementation that closely follows the WhatWG Encoding standard might be better than three or four re-implementations with different performance characteristics or different update schedules.

These views seem antithetical to one another “support everything and support nothing”, but we can have both.
The issue is when your use case doesn’t need it, more encodings are a burden, but when your use case needs it, you really need it and you don’t have a choice.
So, this is what I think the standard should do, it should provide facilities to transcode between Unicode forms and maybe a couple of other popular ones (to be deprecated later), everything else it’s on your own. If you know how the encoding works you can implement it yourself, and you can still use all of the other conveniences.
If your encoding is popular enough, all we have to do is adopt it into the standard and you just delete your implementation, that is it.
And in order for this to work in the future, you can’t just enumerate encodings. No enums.
Have a token type that represents the encoding, and let the type system sort it out, think of it like a compile time dynamic enumeration (/identification).
Identifying the encodings is not the hard part of the API (it should just use text_encoding::id :-)




That’s my 2c



From: Steve Downey <sdowney_at_[hidden]<mailto:sdowney_at_[hidden]>>
Sent: Tuesday, October 27, 2026 23:34
To: SG16 <sg16_at_lists.isocpp.org<mailto:sg16_at_[hidden]>>
Cc: Tiago Freire <tmiguelf_at_[hidden]<mailto:tmiguelf_at_[hidden]>>; Jonathan Wakely <cxx_at_[hidden]<mailto:cxx_at_[hidden]>>
Subject: Re: [isocpp-sg16] P4246R0 Transcoding Text Views and Ranges for WhatWG and iconv


On Tue, Oct 27, 2026, 14:48 Tiago Freire via SG16 <sg16_at_[hidden]<mailto:sg16_at_[hidden]>> wrote:
I think the paper is dead on arrival.
If you have a solution that relies on explicitly enumerating the encodings then you are just asking for trouble, because:
a) You will be stuck maintaining an ever growing list of encodings, and have people fighting who's encoding is relevant to make it onto the list
b) it is a dead end if the encoding you want to work with is not on the list.

That is, though, what the Web platform specifies, in terrible detail. There will never be another legacy encoding added to it, and all of the mappings from labels to the identifiers are fully defined.

I, though, still have three completely unmapped encoding still in production. That's why there is a pluggable variant to use the general framework.
We also taught our fork of gnuiconv about them, which is also why there's an iconv adapter.

A proper solution should allow a user to extend support by themselves and not have to wait for a committee.
It's a hard pass.

It does, just a little further down.

But WHATWG is defined as a closed set, and you must speak it on the web platform. And you must do it the way the web platform tests say it must be done.


________________________________
From: SG16 <sg16-bounces_at_[hidden]<mailto:sg16-bounces_at_[hidden]>> on behalf of Jonathan Wakely via SG16 <sg16_at_[hidden]<mailto:sg16_at_[hidden]>>
Sent: Tuesday, 27 October 2026 18:24:36
To: sg16 <sg16_at_[hidden]<mailto:sg16_at_[hidden]>>
Cc: Jonathan Wakely <cxx_at_[hidden]<mailto:cxx_at_[hidden]>>
Subject: [isocpp-sg16] P4246R0 Transcoding Text Views and Ranges for WhatWG and iconv

I know the paper mentions Eddie's P2728 (Unicode in the library pt 1) and compares them, but I'm not convinced that a completely different API with entirely different names is needed. That seems likely to confuse users.

There seems to be a huge amount of overlap between the codec enum and std::text_encoding::id, why do we need a new enum? Won't that confuse users too?

Why do we need a novel mechanism for mapping encoding labels/names to IDs, isn't that exactly what std::text_encoding does?

Is 'codec' a suitable name? (I don't see that term anywhere in the WhatWG Encoding spec). The paper proposes 'codec' as an enum for identifying an encoding, but then decode_codec and encode_codec as concepts that are modelled by classers that encode and decode ... so is a codec an enum identifying an encoding or a class performing it? It seems to be both. The WhatWG spec uses "encoder" and "decoder", but not "codec".
--
SG16 mailing list
SG16_at_lists.isocpp.org<mailto:SG16_at_[hidden]>
https://lists.isocpp.org/mailman/listinfo.cgi/sg16
Link to this post: http://lists.isocpp.org/sg16/2026/10/4893.php