Date: Tue, 27 Oct 2026 18:34:29 -0400
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
>
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
>
Received on 2026-10-27 22:34:48
