SG16 will hold a meeting *today*, Wednesday, October 22nd, at 19:30 UTC
(timezone conversion
<https://www.timeanddate.com/worldclock/converter.html?iso=20251022T193000&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, well, you're on
your own as I am no longer able to provide a public URL from which to
download one.

For those that subscribe to the WG21 shared calendar, please note that
public subscriptions are no longer available and you likely need to
re-subscribe to a new CalDAV URL. See the recent email sent to the "all"
mailing list or this wiki page
<https://wiki.edg.com/bin/view/Wg21PersistentInformation/CommitteeSharedCalendarInformation>.

Now for the good stuff. The agenda for this meeting includes, you
guessed it, more NB comment processing!

  * US 5-018 <https://github.com/cplusplus/nbballot/issues/592>: 5 [lex]
    Define "whitespace character"
      o P3657R1 <https://isocpp.org/files/papers/P3657R1.pdf>: A Grammar
        for Whitespace Characters
  * 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* argues for adopting P3657 (A Grammar for Whitespace
Characters) <https://isocpp.org/files/papers/P3657R1.pdf> for which a
fresh R1 revision is hot off the press. The paper offers no functional
changes; its goal is to provide a more rigorous definition of what
constitutes whitespace (e.g., comments) and whitespace characters
(space, tab, form feed, etc...) and how they are treated during lexing.
In doing so, the intent is to provide a more solid foundation for future
work along the lines of Corentin's P2348 (Whitespaces Wording Revamp)
<https://wg21.link/p2348>.

We briefly began discussion on *US 189-304* during our last meeting.
This comment 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. On Windows, according to existing implementations,
the intended encoding is determined by querying the AreFileApisANSI()
<https://learn.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-arefileapisansi>
Win32 function. Or maybe not. At least one implementation takes the
choose your own adventure route and yields a different answer if the
current thread has a thread-local locale and that locale uses a UTF-8
encoding. The proposed change includes a few options to consider. No
matter our preferences, we should at least offer a recommendation to do
something about the mysterious note that is [fs.path.type.cvt]p(2.1)
<https://eel.is/c++draft/fs.path.type.cvt#2.1>.

Tom.