<div dir="auto">I am very much in favor of that direction (including not doing anything for 20).<div dir="auto"><br></div><div dir="auto">Thanks Steve!</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Nov 2, 2019, 14:44 Steve Downey &lt;<a href="mailto:sdowney@gmail.com">sdowney@gmail.com</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><h1 style="line-height:1;text-align:center">C++ Identifier Syntax using Unicode Standard Annex 31</h1><table style="border:none;border-collapse:collapse;margin-left:auto;margin-right:auto;margin-top:0.8em;float:right"><tbody><tr><td style="padding-left:1em;padding-right:1em;vertical-align:top">Document #:</td><td style="padding-left:1em;padding-right:1em;vertical-align:top">D19149R0</td></tr><tr><td style="padding-left:1em;padding-right:1em;vertical-align:top">Date:</td><td style="padding-left:1em;padding-right:1em;vertical-align:top">2019-11-02</td></tr><tr><td style="padding-left:1em;padding-right:1em;vertical-align:top">Project:</td><td style="padding-left:1em;padding-right:1em;vertical-align:top">Programming Language C++<br>SG16<br>EWG<br>CWG<br></td></tr><tr><td style="padding-left:1em;padding-right:1em;vertical-align:top">Reply-to:</td><td style="padding-left:1em;padding-right:1em;vertical-align:top">Steve Downey<br>&lt;<a href="mailto:sdowney@gmail.com" style="text-decoration-line:none;color:rgb(65,131,196)" target="_blank" rel="noreferrer">sdowney@gmail.com</a>, <a href="mailto:sdowney2@bloomberg.net" style="text-decoration-line:none;color:rgb(65,131,196)" target="_blank" rel="noreferrer">sdowney2@bloomberg.net</a>&gt;<br></td></tr></tbody></table><div style="color:rgb(0,0,0);font-family:serif;font-size:medium;clear:both"><h1 id="m_-5168074924319414794gmail-abstract" style="line-height:1"><span style="display:inline-block;min-width:35pt">1</span> Abstract<a href="#m_-5168074924319414794_abstract" style="text-decoration-line:none;color:rgb(65,131,196);height:2em;text-align:center;border:none;opacity:0.5;font-family:sans-serif;font-weight:normal;font-size:26.56px" rel="noreferrer"></a></h1><p>In response to NL 029 : Disallow zero-width and control characters</p><p>Adopt Unicode Annex 31 as part of C++ 23. - That C++ identifiers match the pattern (XID_START + _ ) + XID_CONTINUE*. - That portable source is required to be normalized as NFC. - That using unassigned code points ill-formed.</p><h1 id="m_-5168074924319414794gmail-poll-before-discussion" style="line-height:1"><span style="display:inline-block;min-width:35pt">2</span> Poll before discussion<a href="#m_-5168074924319414794_poll-before-discussion" style="text-decoration-line:none;color:rgb(65,131,196);height:2em;text-align:center;border:none;opacity:0.5;font-family:sans-serif;font-weight:normal;font-size:26.56px" rel="noreferrer"></a></h1><p>The current state, allowing control characters, ZWJ, and unassigned codepoints in C++ identifiers is not a defect, and is working as designed, and does not need to be addressed</p><h1 id="m_-5168074924319414794gmail-addressing-identifiers-in-a-more-principled-ways" style="line-height:1"><span style="display:inline-block;min-width:35pt">3</span> Addressing identifiers in a more principled ways<a href="#m_-5168074924319414794_addressing-identifiers-in-a-more-principled-ways" style="text-decoration-line:none;color:rgb(65,131,196);height:2em;text-align:center;border:none;opacity:0.5;font-family:sans-serif;font-weight:normal;font-size:26.56px" rel="noreferrer"></a></h1><p><a href="https://unicode.org/reports/tr31/" style="text-decoration-line:none;color:rgb(65,131,196)" target="_blank" rel="noreferrer">UNICODE IDENTIFIER AND PATTERN SYNTAX</a> is an attempt to provide a normative way of specifying definitions of general-purpose identifiers for use in programming languages. It has evolved signfigantly over the years, in particular since the time that C++ 11 was specified. In particular, the characters that were allowed as identifiers, and the patterns, were not stable at the time of C++11, which is the last time identifiers were addressed in the standard. In addition, at that time, ISO was promulgating advice suggesting a list of code points as the recommended method for ISO standards to specify identifiers.</p><p>Today the definitions in UAX31 can be used to provide stable definitions for programming language identifiers, with guarantees that an identifier will not be invalidated by later standards.</p><p>Originally, UAX31 relied on derived properties of characters, ID_START and ID_CONTINUE, however those properties relied on fundamental properties that could change over time. The unicode database now provides XID_START and XID_CONTINUE, based on the same characteristics, but with an additional stability guarantee. The Unicode database now provides explicit classification of both.</p><p>The original definitions closely match the identifier syntax of C:</p><table style="border:1px solid black;border-collapse:collapse;margin-left:auto;margin-right:auto;margin-top:0.8em"><colgroup><col style="width:0px"><col style="width:0px"></colgroup><thead><tr style="border-bottom:3px double black"><th style="padding-left:1em;padding-right:1em;vertical-align:top;border-bottom:1px solid black"><div><strong>Properties</strong></div></th><th style="padding-left:1em;padding-right:1em;vertical-align:top;border-bottom:1px solid black"><div><strong>General Description of Coverage</strong></div></th></tr></thead><tbody><tr style="border-bottom:1px solid black"><td style="padding-left:1em;padding-right:1em;vertical-align:top">ID_Start</td><td style="padding-left:1em;padding-right:1em;vertical-align:top">ID_Start characters are derived from the Unicode General_Category of uppercase letters, lowercase letters, titlecase letters, modifier letters, other letters, letter numbers, plus Other_ID_Start, minus Pattern_Syntax and Pattern_White_Space code points.</td></tr><tr style="border-bottom:1px solid black"><td style="padding-left:1em;padding-right:1em;vertical-align:top"></td><td style="padding-left:1em;padding-right:1em;vertical-align:top">In set notation:</td></tr><tr style="border-bottom:1px solid black"><td style="padding-left:1em;padding-right:1em;vertical-align:top"></td><td style="padding-left:1em;padding-right:1em;vertical-align:top">[\p{L}\p{Nl}-\p{Pattern_Syntax}-\p{Pattern_White_Space}]</td></tr><tr style="border-bottom:1px solid black"><td style="padding-left:1em;padding-right:1em;vertical-align:top">ID_Continue</td><td style="padding-left:1em;padding-right:1em;vertical-align:top">ID_Continue characters include ID_Start characters, plus characters having the Unicode General_Category of nonspacing marks, spacing combining marks, decimal number, connector punctuation, plus Other_ID_Continue , minus Pattern_Syntax and Pattern_White_Space code points.</td></tr><tr style="border-bottom:1px solid black"><td style="padding-left:1em;padding-right:1em;vertical-align:top"></td><td style="padding-left:1em;padding-right:1em;vertical-align:top">In set notation:</td></tr><tr style="border-bottom:1px solid black"><td style="padding-left:1em;padding-right:1em;vertical-align:top"></td><td style="padding-left:1em;padding-right:1em;vertical-align:top">[\p{ID_Start}\p{Mc}\p{Pc}\p{Other_ID_Continue}-\p{Pattern_Syntax}-\p{Pattern_White_Space}]</td></tr><tr style="border-bottom:1px solid black"><td style="padding-left:1em;padding-right:1em;vertical-align:top"></td><td style="padding-left:1em;padding-right:1em;vertical-align:top"></td></tr></tbody></table><p>The X versions of the properties start the same, but are guaranteed stable in subsequent Unicode standards</p><h1 id="m_-5168074924319414794gmail-issues" style="line-height:1"><span style="display:inline-block;min-width:35pt">4</span> Issues<a href="#m_-5168074924319414794_issues" style="text-decoration-line:none;color:rgb(65,131,196);height:2em;text-align:center;border:none;opacity:0.5;font-family:sans-serif;font-weight:normal;font-size:26.56px" rel="noreferrer"></a></h1><ul style="list-style-type:none;padding-left:2em"><li style="margin-top:0.6em;margin-bottom:0.6em">Continue does not include ZWJ, which some scripts require</li><li style="margin-top:0.6em;margin-bottom:0.6em">Does not exclude homoglyph attack</li><li style="margin-top:0.6em;margin-bottom:0.6em">Does not require the compiler to normalize identifiers</li><li style="margin-top:0.6em;margin-bottom:0.6em">Does not allow emoji</li></ul><h1 id="m_-5168074924319414794gmail-history" style="line-height:1"><span style="display:inline-block;min-width:35pt">5</span> History<a href="#m_-5168074924319414794_history" style="text-decoration-line:none;color:rgb(65,131,196);height:2em;text-align:center;border:none;opacity:0.5;font-family:sans-serif;font-weight:normal;font-size:26.56px" rel="noreferrer"></a></h1><p>Using an explicit list of Unicode characters was considered a best practice for ISO standardization in TR 10176:2003 Guidelines for the preparation of programming language standards.</p><p>National body comment CA 24 for C++11:</p><blockquote><p>A list of issues related TR 10176:2003:</p><ul style="list-style-type:none;padding-left:2em"><li style="margin-top:0.6em;margin-bottom:0.6em">“Combining characters should not appear as the first character of an identifier.” Reference: ISO/IEC TR 10176:2003 (Annex A) This is not reflected in FCD.</li><li style="margin-top:0.6em;margin-bottom:0.6em">Restrictions on the first character of an identifier are not observed as recommended in TR 10176:2003. The inclusion of digits (outside of those in the basic character set) under identifer-nondigit is implied by FCD.</li><li style="margin-top:0.6em;margin-bottom:0.6em">It is implied that only the “main listing” from Annex A is included for C++. That is, the list ends with the Special Characters section. This is not made explicit in FCD. Existing practice in C++03 as well as WG 14 (C, as of N1425) and WG 4 (COBOL, as of N4315) is to include a list in a normative Annex.</li><li style="margin-top:0.6em;margin-bottom:0.6em">Specify width sensitivity as implied by C++03: is not the same as A. Case sensitivity is already stated in [<a href="http://lex.name" target="_blank" rel="noreferrer">lex.name</a>].</li></ul></blockquote><p>N3146 in 2010-10-04 considered using UAX31, but at the time there were stability issues with identifiers, and came down on the side of explicit white listing.</p><p>The Unicode standard has since made stability guarantees about identifiers, and created the XID_START and XID_CONTINUE properties to alleviate the stability concerns that existed in 2010.</p><h1 id="m_-5168074924319414794gmail-wording" style="line-height:1"><span style="display:inline-block;min-width:35pt">6</span> Wording<a href="#m_-5168074924319414794_wording" style="text-decoration-line:none;color:rgb(65,131,196);height:2em;text-align:center;border:none;opacity:0.5;font-family:sans-serif;font-weight:normal;font-size:26.56px" rel="noreferrer"></a></h1><p>Wording to follow based on SG16 and EWG guidance. There is much prior art to follow based on similar proposals and adoption in Rust and Swift.</p><p>Explicit universal character names and codepoints are available for particular Unicode standards from the published database, and could be appended as an appendix.</p></div></div>
_______________________________________________<br>
SG16 Unicode mailing list<br>
<a href="mailto:Unicode@isocpp.open-std.org" target="_blank" rel="noreferrer">Unicode@isocpp.open-std.org</a><br>
<a href="http://www.open-std.org/mailman/listinfo/unicode" rel="noreferrer noreferrer" target="_blank">http://www.open-std.org/mailman/listinfo/unicode</a><br>
</blockquote></div>