SG16 will hold a meeting *today*, Wednesday, October 8th, at 19:30 UTC
(timezone conversion
<https://www.timeanddate.com/worldclock/converter.html?iso=20251008T193000&p1=1440&p2=tz_pdt&p3=tz_mdt&p4=tz_cdt&p5=tz_edt&p6=tz_cest>).

If you need a .ics file to import into your calendar, you can download
it here
<https://documents.isocpp.org/remote.php/dav/public-calendars/R7imgS2LJD9xfeWN/F348AE24-5E93-4596-98A9-4AC123F1BCC0.ics?export>.

The C++26 CD has been published! You've all read every last page in
detail and submitted comments through your NB for the slight
imperfections you think you have found. Those comments have been
compiled, collated, and crunched to produce the classy compendium that
is N5028 <https://wg21.link/n5028>. It is now time to see if your fellow
WG21 members agree with your findings!

  * US 8-021 <https://github.com/cplusplus/nbballot/issues/595>: 5.5p1
    [lex.pptoken] Allow skipping non-preprocessing tokens via #if
  * CA-022 <https://github.com/cplusplus/nbballot/issues/596>: 5.5p1
    [lex.pptoken] Add example for ill-formed non-preprocessing tokens
  * US 63-115 <https://github.com/cplusplus/nbballot/issues/693>:
    16.3.3.3.4.1p01.2 [character.seq.general] Move
    [character.seq.general] to the core wording
  * US 189-304 <https://github.com/cplusplus/nbballot/issues/879>:
    31.12.6.1, 31.12.6.5.6, 31.12.6.5.7, D.22.2 rename filesystem::path
    methods
  * US 5-018 <https://github.com/cplusplus/nbballot/issues/592>: 5 [lex]
    Define "whitespace character"

If you are aware of other NB comments that SG16 should review, please
let me know. The above are all the ones I found that looked relevant.

*US 8-021* and *CA-022* both pose the question of whether a
preprocessing token consisting of a "other" character (e.g., a
non-whitespace character that is not used for lexical purposes outside
of literals; [lex.pptoken] <https://eel.is/c++draft/lex.pptoken>)
renders the program ill-formed if it appears within the group of a
conditional inclusion directive whose control condition evaluates to
false ([cpp.cond] <https://eel.is/c++draft/cpp.cond>). Implementations
tend to think so (https://godbolt.org/z/rahj3jvTo), presumably because
they like [cpp.pre]p5 <https://eel.is/c++draft/cpp.pre#5>, though GCC
appears to be slightly concussed by the example. CA-022 in particular
requests the addition of an example or additional elaboration if the
intent is that the following is ill-formed.

    #if 0
    ` // Ok?
    " // Ok?
    # \N{IDEOGRAPHIC SPACE} else // Ok?
    #endif

*US 63-115* is a request to move the definitions of the execution
character set and execution wide-character set from
[character.seq.general]p(1.2)
<https://eel.is/c++draft/character.seq.general#1.2> in the standard
library wording to [lex.charset] <https://eel.is/c++draft/lex.charset>
in the core language wording. That is where they were prior to
acceptance of P2314R4 (Character sets and encodings)
<https://wg21.link/p2314r4> in C++23. The 2021-02-24
<https://github.com/sg16-unicode/sg16-meetings/blob/master/README-2021.md#february-24th-2021>
and 2021-03-10
<https://github.com/sg16-unicode/sg16-meetings/blob/master/README-2021.md#march-10th-2021>
SG16 meeting summaries contain the discussions of that paper. The
discussion indicates that these terms were retained for compatibility
with the C standard.

*US 189-304* asserts that the system_encoded_string() member function
([fs.path.native.obs] <https://eel.is/c++draft/fs.path.native.obs>) and
its generic sibling added to std::filesystem::path by P2319R5 (Prevent
path presentation problems) <https://wg21.link/p2319r5> are misnamed
because 1) the C++ standard does not have a definition for "system
encoding", and 2) colloquial use of that term would lead readers to an
unintended encoding; raise your hand if you are familiar with the
AreFileApisANSI()
<https://learn.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-arefileapisansi>
Win32 function and its relevance to std::filesystem::path (see the
mysterious note in [fs.path.type.cvt]p(2.1)
<https://eel.is/c++draft/fs.path.type.cvt#2.1>). The proposed change
includes a few options to choose from, but we don't have to limit
ourselves to the options suggested by the /wise/ and /learned/ author of
that comment.

*US 5-018* argues for adopting P3657R0 (A Grammar for Whitespace
Characters) <https://wg21.link/p3657r0> and its proposed changes for the
specification of whitespace characters in lexical analysis. I believe
Alisdair still intends to produce a new revision of this paper, but has
been busy with other higher priority papers. Unless he shows up excited
to share a shiny new revision, we'll postpone discussion of this comment
and the associated paper until next time.

Tom.