On Wed, 28 Oct 2026 at 09:41, Tiago Freire <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]>
> *Sent:* Wednesday, October 28, 2026 09:56
> *To:* Tiago Freire <tmiguelf_at_[hidden]>
> *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, 08:15 Tiago Freire, <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]>
> *Sent:* Tuesday, October 27, 2026 23:34
> *To:* SG16 <sg16_at_[hidden]>
> *Cc:* Tiago Freire <tmiguelf_at_[hidden]>; Jonathan Wakely <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]>
> 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]> on behalf of Jonathan Wakely
> via SG16 <sg16_at_[hidden]>
> *Sent:* Tuesday, 27 October 2026 18:24:36
> *To:* sg16 <sg16_at_[hidden]>
> *Cc:* Jonathan Wakely <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_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg16
> Link to this post: http://lists.isocpp.org/sg16/2026/10/4893.php
>
>