You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
P2843R3 has already been approved for C++26, but SG16 reviewed the change to the handling of vertical white space characters in single line comments during the 2025-07-16 SG16 meeting in anticipation of a possible NB comment. Rough minutes are available in the wiki here and a proper meeting summary will eventually be posted here.
No polls were taken as discussion had not concluded and multiple participants had to leave early leading to a lack of quorum.
The discussion highlighted the tension that exists between wanting to do all of:
Remove undefined behavior and occurrences of ill-formed no diagnostic required wherever possible.
Align the standard with existing practice.
Not break existing source code.
Follow Unicode recommendations.
The discussion acknowledged that the new status quo established by the paper improves on concerns 1 and 2, has no effect on concern 3, but arguably worsens concern 4. Prior to approval of P2843R3, the C++ standard was consistent with Unicode recommendations in prohibiting U+000B LINE TABULATION (VT) and U+000C FORM FEED (FF) (unless followed only by other white space characters) in single line comments, but inconsistent in implicitly allowing other (uncommon) vertical white space characters including U+0085 NEXT LINE (NEL), U+2028 LINE SEPARATOR, and U+2029 PARAGRAPH SEPARATOR. Following approval, all vertical white space characters are now implicitly allowed and treated as horizontal white space which goes against Unicode recommendations.
There was little appetite for requiring a diagnostic for use of vertical white space characters in single line comments without further analysis of impact to existing source code and performance of existing implementations. It was acknowledged that line spoofing is a legitimate concern and statements were made that such concerns are best addressed in the language and not solely a presentation issue.
The discussion suggested a possible emerging consensus for declaring use of vertical white space characters in single line comments as conditionally supported. This would still improve on concern 1, be consistent with concern 2, have no change on concern 3, and retain a non-portable position in the C++ standard regarding use of these characters which helps with concern 4. Allowing implementations to reject programs that use these characters in ways that are not consistent with Unicode recommendations, as they were allowed to prior to P2843R3, would reserve space for future changes to prohibit them unconditionally. The discussion suggested that an NB comment would be useful to engage a wider audience in considering such a change.
Activity
jfbastien commentedon Jun 17, 2023
Not seen in Varna, author wants to update the paper.
27 remaining items
jensmaurer commentedon Jun 20, 2025
CWG 2025-06-20 in Sofia: Approved D2843R3 for plenary straw poll.
P2843R3 Preprocessing is never undefined
P2843R3 Preprocessing is never undefined
P2843R3 Preprocessing is never undefined
tahonermann commentedon Jul 18, 2025
P2843R3 has already been approved for C++26, but SG16 reviewed the change to the handling of vertical white space characters in single line comments during the 2025-07-16 SG16 meeting in anticipation of a possible NB comment. Rough minutes are available in the wiki here and a proper meeting summary will eventually be posted here.
No polls were taken as discussion had not concluded and multiple participants had to leave early leading to a lack of quorum.
The discussion highlighted the tension that exists between wanting to do all of:
The discussion acknowledged that the new status quo established by the paper improves on concerns 1 and 2, has no effect on concern 3, but arguably worsens concern 4. Prior to approval of P2843R3, the C++ standard was consistent with Unicode recommendations in prohibiting U+000B LINE TABULATION (VT) and U+000C FORM FEED (FF) (unless followed only by other white space characters) in single line comments, but inconsistent in implicitly allowing other (uncommon) vertical white space characters including U+0085 NEXT LINE (NEL), U+2028 LINE SEPARATOR, and U+2029 PARAGRAPH SEPARATOR. Following approval, all vertical white space characters are now implicitly allowed and treated as horizontal white space which goes against Unicode recommendations.
There was little appetite for requiring a diagnostic for use of vertical white space characters in single line comments without further analysis of impact to existing source code and performance of existing implementations. It was acknowledged that line spoofing is a legitimate concern and statements were made that such concerns are best addressed in the language and not solely a presentation issue.
The discussion suggested a possible emerging consensus for declaring use of vertical white space characters in single line comments as conditionally supported. This would still improve on concern 1, be consistent with concern 2, have no change on concern 3, and retain a non-portable position in the C++ standard regarding use of these characters which helps with concern 4. Allowing implementations to reject programs that use these characters in ways that are not consistent with Unicode recommendations, as they were allowed to prior to P2843R3, would reserve space for future changes to prohibit them unconditionally. The discussion suggested that an NB comment would be useful to engage a wider audience in considering such a change.
nliber commentedon Jul 18, 2025
P2843R3, not P2843R2, was approved in Sofia.
tahonermann commentedon Jul 18, 2025
Thank you @nliber, I corrected the comment.
wg21bot commentedon Aug 18, 2025
P2843R3 Preprocessing is never undefined (Alisdair Meredith)
[-]P2843 R2 Preprocessing is never undefined[/-][+]P2843 R3 Preprocessing is never undefined[/+]