On Wed, 28 Oct 2026 at 13:02, Tiago Freire <tmiguelf_at_[hidden]> wrote:

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

Maybe if somebody had already written a standard describing exactly how to
perform encoding and decoding for a limited set of character sets with
fixed names.


> 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?
>

Don't the proposed APIs encode to/from char32_t, so UTF-32 is the one that
maps to all of them?


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

That's presumably why the proposed APIs are called whatwg_encode and
whatwg_decode, not universal_encode or generic_encode.

I'm not sure why I'm defending Steve's proposal when I think it has a lot
of problems, but I'm not sure if you've even read it properly.


>
>
>
>
>
>
> *From:* Jonathan Wakely <cxx_at_[hidden]>
> *Sent:* Wednesday, October 28, 2026 13:45
> *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 at 12:37, Tiago Freire <tmiguelf_at_[hidden]> 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!
>
>
>
>
>