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

--- ai12s/ai12-0005-1.txt	2021/11/13 08:12:39	1.51
+++ ai12s/ai12-0005-1.txt	2022/01/28 07:11:19	1.52
@@ -3556,7 +3556,142 @@
 
 ****************************************************************
 
-Editor's note (November 12, 2021): All of the items above this
+From: Randy Brukardt [privately]
+Sent: Friday, December 13, 2021  5:10 PM
+
+7.3.2(5/4) has an Ada 202x change, but no AI nor version change is listed.
+It should have a reference to AI12-0199-1, and be numbered 7.3.2(5/5).
+
+****************************************************************
+
+From: Steve Baird [privately]
+Sent: Tuesday, September 7, 2021  5:56 PM
+
+In 4.2 we've got
+   The expected type for a primary that is a string_literal shall be a 
+   single string type or a type with a specified String_Literal aspect 
+   (see 4.2.1)
+
+This seems fine, but it leads me to wonder about this in 8.6:
+
+    27.a/2  For example, the expected type for a string literal is required
+    to be a single string type. 
+
+Fortunately, it is just AARM text.
+
+****************************************************************
+
+From: Randy Brukardt [privately]
+Sent: Monday, January 10, 2022  9:33 PM
+
+The whole note in question is:
+ 
+For example, the expected type for a string literal is required to be a single 
+string type. But the expected type for the operand of a type_conversion is any 
+type. Therefore, a string literal is not allowed as the operand of a 
+type_conversion. This is true even if there is only one string type in scope 
+(which is never the case). The reason for these rules is so that the compiler 
+will not have to search “everywhere” to see if there is exactly one type in a 
+class in scope.
+ 
+Trying to shoehorn in "type with a specified String_Literal aspect" twice is 
+not pretty.
+ 
+It would probably be easier to rewrite this entire note to use 
+character_literals as the example. That would look like:
+ 
+For example, the expected type for a character literal is required to be a 
+single character type. But the expected type for the operand of a 
+type_conversion is any type. Therefore, a character literal is not allowed 
+as the operand of a type_conversion. This is true even if there is only one 
+character type in scope (which is never the case). The reason for these rules
+is so that the compiler will not have to search “everywhere” to see if there 
+is exactly one type in a class in scope.
+ 
+I don't think we need to mention here that a character literal can also 
+represent the name of a function, as the context in question is one that has
+an expected type (that's part of the wording of the normative rule that this
+note is trying to explain). 
+
+****************************************************************
+
+From: Steve Baird [privately]
+Sent: Thursday, September 30, 2021  12:13 PM
+
+Someone was confused by AARM 6.4.1(5a)'s statement that 
+ "... a type_conversion of a variable is a variable."
+
+Obviously, that statement is only true for a view conversion, not for a value
+conversion.
+
+One could argue that the context already implies that we are only talking about
+view conversions; the note occurs immediately after this RM rule:
+
+   If the mode is in out or out, the actual shall be a name that denotes
+   a variable.
+
+I don't think this argument holds water; I agree that the note is misleading.
+
+Perhaps just replace
+    "type_conversion"
+with
+    "view conversion"
+?
+
+****************************************************************
+
+From: Randy Brukardt [privately]
+Sent: Monday, January 10, 2022  8:39 PM
+
+It is important to look at the entire sentence:
+ 
+   We no longer need “or a type_conversion whose argument is the name of a 
+   variable”, because a type_conversion is now a name, and a type_conversion
+   of a variable is a variable. 
+ 
+Just saying "view conversion" out of the blue wouldn't make a ton of sense 
+(and neither does this statement!). We need to say something about not wanting
+any value conversions here, and that was missing from the original note as
+well. So maybe:
+ 
+   We no longer need “or a type_conversion whose argument is the name of a 
+   variable”, because a type_conversion is now a name, a 
+   {view conversion}[type_conversion] of a variable is a variable {while 
+   any other conversion (which should not be legal here) is a constant}.
+ 
+****************************************************************
+
+An edited private thread between Randy Brukardt and Tucker Taft,
+starting on December 31, 2021 and ending on January 3, 2022.
+
+Randy:
+
+When I was looking for something else in 7.5, I happened to notice 7.5(2.7/5):
+
+  * the base_expression of a record_delta_aggregate (see 4.3.4)
+
+This seems oddly specific, what about the base_expression of an 
+array_delta_aggregate?? It would seem that we would want to make the same 
+"newly created" restriction for it as well.
+
+Tucker:
+
+Array delta aggregates cannot be of a limited type (4.3.4(13/5)).  An AARM
+note would seem appropriate.
+
+Randy:
+
+Thanks. The key here is that a component of a delta aggregate cannot be 
+limited, as they are *assigned* to the component of the base expression;
+it's not possible for them to have build-in-place semantics. A limited
+array has limited components (other than pathologies), so no delta 
+aggregate is possible.
+
+I'll add an AARM note about this.
+
+****************************************************************
+
+Editor's note (January 10, 2022): All of the items above this
 marker have been included in the working version of the AARM.
 
 ****************************************************************