SG16 will hold a meeting today, Wednesday, October 8th, at 19:30 UTC (timezone conversion).
If you need a .ics file to import into your calendar, you can download it here.
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. It is now time to see if your fellow WG21 members agree with your findings!
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]) renders the program ill-formed if it appears within the group of a conditional inclusion directive whose control condition evaluates to false ([cpp.cond]). Implementations tend to think so (https://godbolt.org/z/rahj3jvTo), presumably because they like [cpp.pre]p5, 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) in the standard library wording to [lex.charset] in the core language wording. That is where they were prior to acceptance of P2314R4 (Character sets and encodings) in C++23. The 2021-02-24 and 2021-03-10 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]) and its generic sibling added to std::filesystem::path by P2319R5 (Prevent path presentation problems) 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() Win32 function and its relevance to std::filesystem::path (see the mysterious note in [fs.path.type.cvt]p(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) 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.