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