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?