> 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.
And it doesn’t even cover a fraction of
https://www.iana.org/assignments/character-sets. 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.
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.
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).
That’s my 2c
From: Steve Downey <sdowney@gmail.com>
Sent: Tuesday, October 27, 2026 23:34
To: SG16 <sg16@lists.isocpp.org>
Cc: Tiago Freire <tmiguelf@hotmail.com>; Jonathan Wakely <cxx@kayari.org>
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@lists.isocpp.org> 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.