Date: Mon, 7 Feb 2022 11:29:40 -0500
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.
(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-07 16:29:42