This meeting will be starting in five minutes.

Alisdair has also produced a new draft revision of one of his papers
that addresses some early review feedback; D3658R1
<https://isocpp.org/files/papers/D3556R1.pdf>.

Tom.

On 5/13/25 11:31 PM, Tom Honermann via SG16 wrote:
>
> 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.
>
>