Another difference is that WhatWG says that "windows1252", "latin1" and
"ascii" are all the same thing, whereas those labels belong to three
separate text_encoding::id values. I would still prefer to reuse
text_encoding in this proposal, and maybe say that using any of
text::encoding::ASCII, text_encoding::ISOLatin1, and
text_encoding::windows1252 all give you the same kind of whatwg
encoding/decoding.

If you absolutely *must* introduce a new enum, there needs to be an API to
convert back and forth between the two enums. Maybe just specify the values
of your enumerators in terms of the existing ones, so that a cast is
sufficient to do the conversion between them.


On Tue, 27 Oct 2026 at 18:01, Jonathan Wakely <cxx_at_[hidden]> wrote:

> I checked every one of them, and all the codec enumerators are already
> present as enumerators of std::text_encoding::id, except for the special
> values "replacement" and "x-user-defined", and maybe x-mac-cyrillic (is
> that the same as csISO111ECMACyrillic a.k.a ECMA-cyrillic a.k.a KOI8-E?)
>
> Surely we could reuse std::text_encoding::id? Maybe specify the mapping
> between the names in https://encoding.spec.whatwg.org/#names-and-labels
> and std::text_encoding::id values (for the subset of id values that
> correspond to one of the WhatWG encodings). Then the lookup can be
> specified to return a value of std::text_encoding::id. Most of the labels
> in the WhatWG spec already match an alias of the corresponding
> text_encoding::id, but we could just require that the lookup for this
> feature maps the labels to an id.
>
>
> On Tue, 27 Oct 2026 at 17:34, Jonathan Wakely <cxx_at_[hidden]> wrote:
>
>>
>>
>> On Tue, 27 Oct 2026 at 17:24, Jonathan Wakely <cxx_at_[hidden]> wrote:
>>
>>> 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".
>>>
>>
>> Oh, also the paper claims that the values of the codec enumerators are
>> not specified, which contradicts the wording. If you want the values of the
>> enumerators to be unspecified, you need to say so in the wording.
>>
>> "Each enumerator names the encoding of the same name in the WHATWG
>> Encoding Standard, whose table of encodings is normative and is not
>> restated here: an encoding is what that standard says it is, and a
>> specification that copied the list would be a second one to keep current."
>>
>> This is not wording. An enumerator doesn't name something from another
>> document, it names a constant. The rest of the sentence seems like
>> rationale for the format of the specification, but is not specification.
>>
>>
>> After the <transode> synopsis there are a load of *Remarks*: and
>> *Constraints*: paragraphs that don't seem attached to anything. Were the
>> paragraphs in the wording subjected to a random shuffle?
>>
>>
>>
>>
>