This meeting is starting 5 minutes ago...

Tom.

On 10/8/25 1:12 AM, Tom Honermann via SG16 wrote:
>
> 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.
>
>