Date: Tue, 13 May 2025 23:31:58 -0400
SG16 will hold a meeting *today/tomorrow*, Wednesday, May 14th, at 19:30
UTC (timezone conversion
<https://www.timeanddate.com/worldclock/converter.html?iso=20250514T193000&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, you can download
it here
<https://documents.isocpp.org/remote.php/dav/public-calendars/R7imgS2LJD9xfeWN/94A3D3A0-70B9-4847-935F-9453DB2BB216.ics?export>.
The agenda follows.
* P3658R0: Adjust /identifier/ following new Unicode recommendations
<https://wg21.link/p3658r0>.
* P3556R0: Input files are source files <https://wg21.link/p3556r0>.
* P3657R0: A Grammar for Whitespace Characters
<https://wg21.link/p3657r0>.
*P3658R0*, by our good friend Robin Leroy, seeks to adjust the character
allowances for identifiers to include a more consistent set of
mathematical symbols. This recommendation comes from the UTC in the wake
of the adoption of P1949R7 (C++ Identifier Syntax using Unicode Standard
Annex 31) <https://wg21.link/p1949r7> for C++23, a paper I'm sure you
all remember well. Deployment of P1949 was found to break some existing
code that used identifiers containing mathematical symbols that were
made invalid by the adoption of P1949R7, but that seemed quite
reasonable considering similar identifiers that were not made invalid.
The UTC investigated and produced a recommendation for general purpose
programming languages as published in UTS #55 (Unicode Source Code
Handling) <https://www.unicode.org/reports/tr55/>. The Unicode stability
policy prohibited directly changing the XID_Start and XID_Continue
properties, so a Mathematical Compatibility Notation Profile
<https://www.unicode.org/reports/tr31/#Mathematical_Compatibility_Notation_Profile>
was defined with corresponding ID_Compat_Math_Start
<https://util.unicode.org/UnicodeJsps/list-unicodeset.jsp?a=%5B%3AID_Compat_Math_Start%3A%5D&g=&i=>
and ID_Compat_Math_Continue
<https://util.unicode.org/UnicodeJsps/list-unicodeset.jsp?a=%5B%3AID_Compat_Math_Continue%3A%5D&g=&i=>
properties to identify the member characters. The proposed changes are
rather straight forward; modify the /identifier-start/
<https://eel.is/c++draft/lex.name#nt:identifier-start> and
/identifier-continue/
<https://eel.is/c++draft/lex.name#nt:identifier-continue> grammar
productions to include characters identified by the new properties.
*P3556R0* and *P3657R0* come to us courtesy of Alisdair Meredith. These
papers are intended to clarify core language wording related to
input/source file terminology and the specification of whitespace
characters. Both papers are near editorial in nature, but sufficiently
complicated to warrant CWG review; SG16 was requested to review since
these touch topics near and dear to us. P3556R0 does not include any
intended impact to existing implementations. P3657R0 includes two
normative changes; it addresses CWG 1655 (Line endings in raw string
literals) <https://wg21.link/cwg1655> and it removes a case of IFNDR
from [lex.comment]p1 <https://eel.is/c++draft/lex.comment#1.sentence-4>
as previously proposed by Corentin in P2348R3 (Whitespaces Wording
Revamp) <https://wg21.link/p2348r3>.
Tom.
UTC (timezone conversion
<https://www.timeanddate.com/worldclock/converter.html?iso=20250514T193000&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, you can download
it here
<https://documents.isocpp.org/remote.php/dav/public-calendars/R7imgS2LJD9xfeWN/94A3D3A0-70B9-4847-935F-9453DB2BB216.ics?export>.
The agenda follows.
* P3658R0: Adjust /identifier/ following new Unicode recommendations
<https://wg21.link/p3658r0>.
* P3556R0: Input files are source files <https://wg21.link/p3556r0>.
* P3657R0: A Grammar for Whitespace Characters
<https://wg21.link/p3657r0>.
*P3658R0*, by our good friend Robin Leroy, seeks to adjust the character
allowances for identifiers to include a more consistent set of
mathematical symbols. This recommendation comes from the UTC in the wake
of the adoption of P1949R7 (C++ Identifier Syntax using Unicode Standard
Annex 31) <https://wg21.link/p1949r7> for C++23, a paper I'm sure you
all remember well. Deployment of P1949 was found to break some existing
code that used identifiers containing mathematical symbols that were
made invalid by the adoption of P1949R7, but that seemed quite
reasonable considering similar identifiers that were not made invalid.
The UTC investigated and produced a recommendation for general purpose
programming languages as published in UTS #55 (Unicode Source Code
Handling) <https://www.unicode.org/reports/tr55/>. The Unicode stability
policy prohibited directly changing the XID_Start and XID_Continue
properties, so a Mathematical Compatibility Notation Profile
<https://www.unicode.org/reports/tr31/#Mathematical_Compatibility_Notation_Profile>
was defined with corresponding ID_Compat_Math_Start
<https://util.unicode.org/UnicodeJsps/list-unicodeset.jsp?a=%5B%3AID_Compat_Math_Start%3A%5D&g=&i=>
and ID_Compat_Math_Continue
<https://util.unicode.org/UnicodeJsps/list-unicodeset.jsp?a=%5B%3AID_Compat_Math_Continue%3A%5D&g=&i=>
properties to identify the member characters. The proposed changes are
rather straight forward; modify the /identifier-start/
<https://eel.is/c++draft/lex.name#nt:identifier-start> and
/identifier-continue/
<https://eel.is/c++draft/lex.name#nt:identifier-continue> grammar
productions to include characters identified by the new properties.
*P3556R0* and *P3657R0* come to us courtesy of Alisdair Meredith. These
papers are intended to clarify core language wording related to
input/source file terminology and the specification of whitespace
characters. Both papers are near editorial in nature, but sufficiently
complicated to warrant CWG review; SG16 was requested to review since
these touch topics near and dear to us. P3556R0 does not include any
intended impact to existing implementations. P3657R0 includes two
normative changes; it addresses CWG 1655 (Line endings in raw string
literals) <https://wg21.link/cwg1655> and it removes a case of IFNDR
from [lex.comment]p1 <https://eel.is/c++draft/lex.comment#1.sentence-4>
as previously proposed by Corentin in P2348R3 (Whitespaces Wording
Revamp) <https://wg21.link/p2348r3>.
Tom.
Received on 2025-05-14 03:32:05