CVS difference for ai12s/ai12-0005-1.txt

--- ai12s/ai12-0005-1.txt	2019/03/09 05:06:41	1.27
+++ ai12s/ai12-0005-1.txt	2019/04/03 07:15:09	1.28
@@ -1258,7 +1258,7 @@
 
 2.9 (3.g/5) : 2012=> 2020
 
-3.10.2 (23.r/4) : (is) leads
+3.10.2 (23.r/4) : (is) leads  [Editor's note: this is really 3.10.1 (23.r/4).]
 
 6.1.1 (41.e/4) these are not [be] allowed
 
@@ -1328,7 +1328,88 @@
 
 **************************************************************
 
-Editor's note (March 08, 2019): All of the items above this
+From Steve Baird's RM review:
+
+3.10.2(7.b/4) says (as per AI12-0005)
+      "... as well as the accessibility level of anonymous access types in a
+         component_definition"
+   Should "in" be replaced with "defined by"? [Yes - Editor.]
+
+In 3.10.2(19.3/4) we say
+     "... when within ... or the return expression of expression function F,
+     the <blah blah blah> is presumed to be the same as that of the level of
+     the master that elaborated the body of F."
+Is it ok to talk about elaborating the body of an expression function?
+
+[Editor's reply:
+It's bit iffy, because there isn't a static definition of the "body" of an 
+expression function. But the only way to reword this would require a separate 
+(and long) sentence only about expression functions. That seems like overkill. 
+I added a To Be Honest note about this:
+
+    For an expression function F, the "body of F" is the 
+    expression_function_declaration of F.]
+
+***************************************************************
+
+From: Bob Duff
+Sent: Monday, April 1, 2019  2:49 PM
+
+Maybe you can handle this as a simple editorial fix in 2.3:
+
+4.1/5 {AI12-0004-1} {AI12-0263-1} An identifier shall only contain characters 
+that may be present in Normalization Form KC (as defined by Clause 21 of 
+ISO/IEC 10646:2017).
+
+4.b/5       Implementation Note: An implementation can usually detect this
+            during lexical processing. The code points not allowed are those
+            for which Unicode property NFKC_QC (Normalization Form KC
+            Quick_Check) has the value No. We say "might be allowed" so that
+
+No, we don't.  We say "may be present".
+
+            characters for which the value is Maybe (really, one of the
+            possible values is Maybe) are allowed (these are mainly combining
+            marks). The necessary tables can be found in
+            http://www.unicode.org/Public/UCD/latest/ucd/DerivedNormalizationProps.txt
+            . Versions for older Unicode versions can be found on this site as
+            well; start at http://www.unicode.org/Public/ and find the
+            appropriate version number.
+
+**************************************************************
+
+From Ed Schonberg's RM review:
+
+12.5.1 (5.g/4)      types [that differ from the kind] {whose 
+kind differs from that of}
+
+12.6 (8.e.2/5) ..of [an] {a} formal abstract subprogram.
+ 
+> 13.1.1 (18.c/5)  … they all have to specify the same 
+> [primitive of T]  value for that aspect  )?)   Explanation is garbled.
+
+**************************************************************
+
+From Tucker Taft's RM review:
+
+8.1(18.t/4)
+... Note that some implementations already allow this common 
+sense interpretation, so this extension [may]{might} in fact 
+{already} be used in existing code. 
+
+8.5.1(4.a/5)
+   [This rule prevents] {These rules prevent} "lying". ...
+
+**************************************************************
+
+From Brad Moore's RM review:
+
+13.14(3.g/4) Ramification: Note that the rule about proper 
+bodies [being]{causing} freezing only applies in declarative_parts.
+
+**************************************************************
+
+Editor's note (April 2, 2019): All of the items above this
 marker have been included in the working version of the AARM.
 
 ****************************************************************