C++ Logo

sg16

Advanced search

Re: [isocpp-sg16] Agenda for the 2025-10-22 SG16 meeting

From: Tom Honermann <tom_at_[hidden]>
Date: Tue, 4 Nov 2025 00:41:47 -0500
My rough notes for this meeting are available on the WG21 wiki here
<https://wiki.edg.com/bin/view/Wg21telecons2025/SG16Teleconference2025-10-22>.

The P3657 GH issue <https://github.com/cplusplus/papers/issues/2287> has
been updated to reflect the SG16 consensus to forward the paper to CWG.
Likewise, the US 5-018 GH issue
<https://github.com/cplusplus/nbballot/issues/592> has been updated to
reflect the recommendation to adopt P3657R1
<https://isocpp.org/files/papers/P3657R1.pdf> as its resolution.
Alisdair has produced a draft P3657R2 that references the SG16
discussion and incorporates a fix for editorial issue 5502
([lex.pptoken] p2 Split the quotation characters into the corresponding
terms) <https://github.com/cplusplus/draft/issues/5502> in the proposed
changes for [lex.whitespace.char]p1 (see note 2 and the reference to
quotation mark characters via U+0027 APOSTROPHE and U+0022 QUOTATION MARK).

The US 189-304 GH issue
<https://github.com/cplusplus/nbballot/issues/879> has been updated to
reflect the SG16 recommendation to rename
[generic_]system_encoded_string() to [generic_]native_encoded_string().

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.
>
>

Received on 2025-11-04 05:41:49