I will treat this as feedback for R5 of the paper. Barring errors, I am treating r4 as if it were submitted for mailing, and will do so before posting to the EWG reflector. 

On Wed, May 27, 2020, 17:43 Tom Honermann via SG16 <sg16@lists.isocpp.org> wrote:
Since we just polled a revision without updates to address Alisdair's feedback below, I'd like to request that any updates done based on this feedback go into a new revision.  Let's treat these comments as if they are early EWG feedback.

Tom.

On 5/27/20 3:45 PM, Alisdair Meredith via SG16 wrote:
More non-technical feedback, none of this should affect SG16.

For 6.1, so not assume a wider audience in EWG will immediately
know that ZWJ is a Zero Width Joiner.  A clearer title or Captializing
The Term may help?  Possibly state what a zero width joiner is
before noting that some scripts rely on them?

(Yes, we can work this out easily enough, but I aspire to papers
that are simple to read without back-tracking).

8 : after explaining normalization form C, conclude the example by
explaining how À is represented in this form.


Is it worth calling out in the ABI compatibility note that we wound be
breaking compatibility between versions of the same compiler, in
order to achieve compatibility between all compilers on that platform?
It is inferred, but I think might be clearer.

9.2 R3 are these the patterns that the pattern matching papers will
introduce a need for?  Maybe add a ‘yet’ if so.

AlisdairM

On May 27, 2020, at 19:32, Steve Downey via SG16 <sg16@lists.isocpp.org> wrote:


On Wed, May 27, 2020 at 2:21 PM Steve Downey <sdowney@gmail.com> wrote:
Adopted the changes, except for the footnote, which corresponds to how the LaTeX is marked up, with the \footnote inline in the text. The footnote doesn't actually move, it's the rest of the text around it. 

On Wed, May 27, 2020 at 1:24 AM Tom Honermann <tom@honermann.net> wrote:
Thanks, Steve.  A few nit-picky comments below.

In the new "Summary" section, in addition to noting that emoji will no longer be allowed in identifiers, I think it would be helpful to note that identifiers previously allowed for some scripts will no longer be allowed.  This is mentioned in section 6.1, but I think also worthy of mention in the summary.

In section 7, there is an instance of "C++. C++.".

Section 7 states that N3146 "considered using UAX31".  My reading of N3146 is that it did use UAX #31, but it adapted what was then called the "Alternative Identifier Syntax" option.  Unicode 9 renamed "Alternative Identifier Syntax" to "Immutable Identifiers".  The relevant text from N3146 is:

The set of UCNs disallowed in identifiers in C and C++ should exactly match the specification in [AltId], with the following additions: all characters in the Basic Latin (i.e. ASCII, basic source character) block, and all characters in the Unicode General Category "Separator, space".

[AltId] corresponds to:
Unicode Standard Annex #31: Unicode Identifier and Pattern Syntax, "Alternative Identifier Syntax", http://www.unicode.org/reports/tr31/tr31-11.html#Alternative_Identifier_Syntax

Section 7 also states, "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."  However, the Unicode 5.2 version of UAX #31 referenced by N3146 does reference XID_Start and XID_Continue.  It looks to me like the XID properties have been around since at least 2005 and Unicode 4.  Perhaps the XID properties were not stable at that time?  Regardless, it looks like the quoted sentence needs an update.

In section 9.3, the sub-sections are arguably out of order.  The first two sub-sections are for R1 and R4 (requirements that are met), and the remaining sub-sections list requirements that are not met (including R1a, R1b, R2, and R3).  I think the sub-section order should follow the requirement order (R1, R1a, R1b, R2, R3, R4, ...)

In section 10, the end of the first paragraph appears to be missing an "XID"; "... character classes XID_Start and _Continue."

In the wording for [lex.name]p1, the footnote is moved into the paragraph, but still states "footnote" instead of "note".  If this is because Jens indicated this is how the editors expect relocation of a footnote to be communicated, then ignore this comment.

In the wording for [lex.name]p1, the copied footnote text doesn't match the WP.  There is a missing "\u in".

In the annex wording for X.2 R1, can we avoid duplicating the grammar specification from [lex.name]?

Tom.

On 5/26/20 4:51 PM, Steve Downey via SG16 wrote:
Find attached a draft of the UAX31 paper for discussion. 
Viewable at http://htmlpreview.github.io/?https://github.com/steve-downey/papers/blob/master/generated/p1949.html
Source at https://github.com/steve-downey/papers/blob/master/p1949.md

(note that github doesn't format the same way that mpark's WG21 format does)


<p1949.html>-- 
SG16 mailing list
SG16@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/sg16



--
SG16 mailing list
SG16@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/sg16