It sounds like I'll be dialing in from my "nice vacation at home".

-- HT

On Wed, Oct 8, 2025 at 1:12 AM Tom Honermann via SG16 <sg16_at_[hidden]>
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 8-021 is premised on a misreading of the text. The wording it cites
basically says that this is okay:
#if 0
#line ( // relaxed directive syntax
#endif

CA-022 demonstrates the status quo wording. It intends to emphasize that
implementations have bugs in this area.


> *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.
>
For consideration:

> Each element of the execution wide-character set is encoded as a single
> code unit representable by a value of type wchar_t.


should change alongside *library* updates when we move to C26 (or higher),
incorporating https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3366.htm.

*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.
>
I think the function name should have "api" somewhere to avoid the
impression that the underlying filesystem data structures necessarily uses
the encoding.

> *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.
> --
> SG16 mailing list
> SG16_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg16
> Searchable archives: http://lists.isocpp.org/sg16/2025/10/index.php
>