SG16 will hold a telecon on Wednesday, November 30th, at 19:30 UTC
(timezone conversion
<https://www.timeanddate.com/worldclock/converter.html?iso=20221130T193000&p1=1440&p2=tz_pst&p3=tz_mst&p4=tz_cst&p5=tz_est&p6=tz_cet>).

*This message will also serve as your friendly reminder that this
meeting is taking place tomorrow. **I'm sorry for publishing an agenda
so very late. *

*For participants in the USA, please note that daylight savings time
ended 2022-11-06, so this telecon will start one hour earlier than our
last telecon.*

The agenda follows. We won't get through all of these. These are all of
the NB comments we have left to address. Whatever we don't get to in
this meeting will be scheduled for the December 14th meeting.

  * P2713R0: Escaping improvements in std::format
    <https://wg21.link/p2713r0>
      o US 38-098 22.14.6.4p1 [format.string.escaped] Escaping for
        debugging and logging
        <https://github.com/cplusplus/nbballot/issues/515>
      o FR 005-134 22.14.6.4 [format.string.escaped] Aggressive escaping
        <https://github.com/cplusplus/nbballot/issues/408>
  * P2693R0: Formatting thread::id and stacktrace
    <https://wg21.link/p2693r0>
      o FR-008-011 22.14 [format] Support formatting of thread::id
        <https://github.com/cplusplus/nbballot/issues/410>
  * FR-010-133 [Bibliography] Unify references to Unicode
    <https://github.com/cplusplus/nbballot/issues/412> and
    FR-021-013 5.3p5.2 [lex.charset] Codepoint names in identifiers
    <https://github.com/cplusplus/nbballot/issues/423>
  * P2675R0: LWG3780: The Paper (format's width estimation is too
    approximate and not forward compatible) <https://wg21.link/p2675r0>
      o LWG #3780: format's width estimation is too approximate and not
        forward compatible <https://cplusplus.github.io/LWG/issue3780>
      o FR-007-012 22.14.2.2 [format.string.std] codepoints with width 2
        <https://github.com/cplusplus/nbballot/issues/409>
  * FR-020-014 5.3 [lex.charset] Replace "translation character set" by
    "Unicode" <https://github.com/cplusplus/nbballot/issues/422>

P2713R0 <https://wg21.link/p2713r0> (Escaping improvements in
std::format) implements the SG16 proposed resolutions for US 38-098
<https://github.com/cplusplus/nbballot/issues/515> (see the 2022-10-19
SG16 meeting summary
<https://github.com/sg16-unicode/sg16-meetings#october-19th-2022>) and
FR 005-134 <https://github.com/cplusplus/nbballot/issues/408> (see the
2022-11-02 SG16 meeting summary
<https://github.com/sg16-unicode/sg16-meetings#november-2nd-2022>).
We'll review the wording and then poll forwarding to LEWG as the
resolution of the two NB comments.

    Candidate Poll 1: P2713R0: Forward to LEWG as the recommended
    resolution of US 38-098 and FR 005-134 [amended to ...].

P2693R0 <https://wg21.link/p2693r0> (Formatting thread::id and
stacktrace) is intended to resolve FR-008-011
<https://github.com/cplusplus/nbballot/issues/410>. I did not initially
tag this NB comment as needing SG16 review, but Bryce requested that
SG16 take a look, specifically with regard to narrow vs wide formatting.
Bryce has indicated this paper will need to be approved soon in order
for it to appear in the electronic polling that will be conducted in
January.

    Candidate Poll 2: P2693R0: Forward to LEWG as the recommended
    resolution of FR-008-011 [amended to ...].

FR-010-133 <https://github.com/cplusplus/nbballot/issues/412> and
FR-021-013 <https://github.com/cplusplus/nbballot/issues/423> were
discussed during the 2022-11-02 SG16 meeting
<https://github.com/sg16-unicode/sg16-meetings#november-2nd-2022> and
concluded with a recommendation to discuss with the project editor the
possibility of preferring the Unicode Standard over ISO/IEC 10646 within
the C++ standard. The project editor approved this direction and we can
now move forward with drafting wording changes. This will require a
paper produced in short order if it is to be accepted for C++23.

P2675R0 <https://wg21.link/p2675r0> (LWG3780: The Paper (format's width
estimation is too approximate and not forward compatible)) is intended
to resolve LWG #3780 <https://cplusplus.github.io/LWG/issue3780> and
FR-007-012 <https://github.com/cplusplus/nbballot/issues/409>. It seeks
to replace the explicit list of code point ranges in
[format.string.std]p12 <https://eel.is/c++draft/format.string.std#12>
with wording that derives substantially the same set of code points
using Unicode database properties.

    Candidate Poll 3.1: P2675R0: Forward to LEWG as the recommended
    resolution of FR-007-012 [amended to ...].
    Candidate Poll 3.2: P2675R0: Forward to LEWG for C++26 [amended to ...].
    Candidate Poll 3.3: Recommend to LEWG that FR-007-012 be rejected.

FR-020-014 <https://github.com/cplusplus/nbballot/issues/422> raises
concerns that were discussed as part of the reviews of P2314
<https://wg21.link/p2314> and P2297 <https://wg21.link/p2297> during the
2021-03-24 SG16 meeting
<https://github.com/sg16-unicode/sg16-meetings/blob/master/README-2021.md#march-24th-2021>.
The comment does not appear to present new information. If we choose to
accept, a paper will need to be quickly produced.

    Candidate poll 4.1: Recommend to CWG that FR-020-014 be accepted.
    Candidate poll 4.2: Recommend to CWG that FR-020-014 be rejected.

Tom.