This is your friendly reminder that this meeting is happening today.

Tom.

On 7/13/25 1:29 AM, Tom Honermann via SG16 wrote:

SG16 will hold a meeting on Wednesday, July 16th, at 19:30 UTC (timezone conversion).

If you need a .ics file to import into your calendar, you can download it here.

The agenda follows.

P2843R2: Preprocessing is never undefined.

LWG issue 4070: Transcoding by std::formatter<std::filesystem::path>.

LWG issue 4090: Underspecified use of locale facets for locale-dependent std::format.

P2843R2 was approved for C++26 in Sofia. Though this paper has been around for a while, it wasn't on my radar for SG16 review until recently and scheduling conflicts prevented SG16 review in advance of the Sofia meeting. The paper amends [lex.comment]p1 to strike the highlighted wording below.

The characters /* start a comment, which terminates with the characters */. These comments do not nest. The characters // start a comment, which terminates immediately before the next new-line character. If there is a form-feed or a vertical-tab character in such a comment, only whitespace characters shall appear between it and the new-line that terminates the comment; no diagnostic is required.

The status quo is thus that the following vertical whitespace characters may now appear anywhere in both block and line comments (note that U+000A {LINE FEED (LF)} and U+000D {CARRIAGE RETURN (CR)} form new-line characters for UTF-8 input files; for other input files, new-line is implementation-defined ([lex.phases]p1)).

U+000B LINE TABULATION (VT)

U+000C FORM FEED (FF)

U+0085 NEXT LINE (NEL)

U+2028 LINE SEPARATOR

U+2029 PARAGRAPH SEPARATOR

These characters likely don't pose a concern in block comments, but their allowance in line comments allows for line break spoofing. For this reason, the Unicode standard recommends that computer languages meet the UAX31-R3a requirement described in UAX #31 section 4.1, "Whitespace"; see UTS #55 section 3.2, "Whitespace and Syntax", the description of line break spoofing in section 1.2.1, "Line Break Spoofing", presentation recommendations in section 4.1.1, "Atoms", the Unicode 16.0 section 5.8, "Newline Guidelines", and finally UAX #14 section 6, "Line Breaking Algorithm". C++ does not currently claim conformance with the UAX31-R3a requirement ([uaxid.pattern]).

There are at least a couple of ways in which the line break spoofing concerns can be mitigated:

By mapping all vertical whitespace characters to new-line and thereby conforming to UAX31-R3a-1.

By prohibiting vertical whitespace characters that are not mapped to new-line in line comments thereby conforming to UAX31-R3a-2 (with the declaration of a profile).

Alternatively, this concern can be deemed a presentation issue that does not warrant language restrictions.

This issue was discussed in EWG in Sofia. The minutes are very terse though. EWG was apparently reluctant to adopt the Unicode recommendation, but did not want to preserve the previous status-quo of (some) vertical whitespace characters rendering the program IFNDR. Some implementors expressed concerns that existing implementations take advantage of vector instructions to quickly scan and discard line comments and that a requirement to diagnose would prevent such techniques. I extended an invitation to the people that made those comments to attend the SG16 meeting so that this concern can be clearly discussed.

An NB comment is anticipated; this discussion is intended to prepare SG16 to offer a recommendation.

LWG 4070 and LWG 4090 were last discussed by SG16 during the 2024-06-12 SG16 meeting. Proposed resolutions guided by the previous SG16 discussion were recently drafted. We'll review and poll forwarding to LWG.

Tom.