C++ Logo


Advanced search

Re: Agenda for the 2022-02-09 SG16 telecon

From: Tom Honermann <tom_at_[hidden]>
Date: Wed, 9 Feb 2022 11:05:32 -0500
This is your friendly reminder that this telecon is taking place *TODAY*.

I apologize for failing to get an email reminder sent yesterday. My
laptop died and I'm even further behind than usual.

I also apologize for not yet publishing the meeting summary for the last
telecon; see above.


On 2/7/2022 11:29 AM, Tom Honermann via SG16 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>
> o Continue prior discussion and poll.
> * P2513R0: char8_t Compatibility and Portability Fixes
> <https://wg21.link/p2513r0>
> o 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.

Received on 2022-02-09 16:05:33