Please note that P1885 was updated (again) to address P2498. I encourage people to read the paper. 

https://isocpp.org/files/papers/P1885R10.pdf

Thank you for mentioning that Corentin; I apologize that I neglected to do so.

As Corentin requests, please do familiarize yourself with the changes made.

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

I think that is the correct choice; any agreed upon design changes can and should be handled by a new paper.

Tom.

On Mon, Feb 7, 2022 at 5:29 PM Tom Honermann via SG16 <sg16@lists.isocpp.org> wrote:

SG16 will hold a telecon on Wednesday, February 9th at 19:30 UTC (timezone conversion).

The agenda is:

• P2498R1: Forward compatibility of text_encoding with additional encoding registries
• Continue prior discussion and poll.
  
• P2513R0: char8_t Compatibility and Portability Fixes
• Initial review.
  

We last discussed P2498R0 at our 2022-01-12 telecon, 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 for C++23.

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 (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.

Tom.

--
SG16 mailing list
SG16@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/sg16