This meeting is starting now-ish.

Tom.

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