Please note that P1885 was updated (again) to address P2498. I encourage
people to read the paper.
https://isocpp.org/files/papers/P1885R10.pdf

I do not intend to make further design changes to P1885 that do not get
first approved by LEWG

On Mon, Feb 7, 2022 at 5:29 PM Tom Honermann via SG16 <sg16_at_[hidden]>
wrote:

> SG16 will hold a telecon on Wednesday, February 9th at 19:30 UTC (timezone
> conversion
> <https://www.timeanddate.com/worldclock/converter.html?iso=20220209T193000&p1=1440&p2=tz_pst&p3=tz_mst&p4=tz_cst&p5=tz_est&p6=tz_cet>
> ).
>
> The agenda is:
>
> - P2498R1: Forward compatibility of text_encoding with additional
> encoding registries <https://wg21.link/p2498r1>
> - Continue prior discussion and poll.
> - P2513R0: char8_t Compatibility and Portability Fixes
> <https://wg21.link/p2513r0>
> - Initial review.
>
> We last discussed P2498R0 <https://wg21.link/p2498r0> at our 2022-01-12
> telecon <https://github.com/sg16-unicode/sg16-meetings#january-12th-2022>,
> but did not poll then due to lack of quorum. A new revision has since been
> published to address concerns raised during that discussion. We'll continue
> discussion, and then, assuming quorum, poll further direction or forwarding
> of the proposal. Potential polls are listed below ordered from more
> abstract to concrete.
>
> 1. The text_encoding class design should be modified to facilitate
> potential future association with additional encoding registries without
> retaining a bias towards the IANA registry.
> 2. The text_encoding class should be modified to make the association
> to the IANA character set registry explicit in the interface.
> 3. Forward P2498R1 as proposed (or with changes as discussed) to LEWG
> as an amendment of P1885 <https://wg21.link/p1885> for C++23.
>
> P2513R0 <https://wg21.link/p2513r0> intends to reduce the backward
> compatibility impact of the C++20 introduction of char8_t by restoring
> the ability to initialize an array of char, signed char, and unsigned char
> with UTF-8 string literals. The motivation is to restore compatibility with
> C and to restore the explicit ability to use UTF-8 data in [signed/
> unsigned] char-based storage without having to explicitly copy bytes, but
> without otherwise relaxing type constraints with char8_t. WG14 will be
> considering N2653
> <http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2653.htm> (char8_t: A
> type for UTF-8 characters and strings (Revision 1)) next week. If accepted
> as proposed, C23 will introduce a char8_t typedef of unsigned char, but
> will not restrict initialization behavior as C++20 did. Discussion at this
> telecon may provide input to WG14 next week. Based on discussion, we may
> elect to delay forwarding this paper until WG14 has discussed and polled
> N2653 <http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2653.htm>.
>
> Tom.
> --
> SG16 mailing list
> SG16_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg16
>