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

--- ai12s/ai12-0368-1.txt	2020/03/06 04:48:47	1.1
+++ ai12s/ai12-0368-1.txt	2020/03/10 04:13:21	1.2
@@ -1,4 +1,4 @@
-!standard 4.9(8)                                     20-03-05  AI12-0368-1/01
+!standard 4.9(8)                                     20-03-09  AI12-0368-1/02
 !standard 4.9(12.1/3)
 !standard 4.9(17)
 !standard 6.1.1(24.2/5)
@@ -69,12 +69,18 @@
    AARM Reason: We disallow components that depend on a discriminant so that 
    no discriminant checks are needed to evaluate the selected_component.
 
- * is an indexed_component whose prefix statically names an object, the object
-   is statically constrained, and the index expressions of the object are 
-   static and have values that are within the range of the index constraint. 
+ * is an indexed_component whose prefix statically names an object, there 
+   is no implicit dereference of the prefix, the object is statically 
+   constrained, and the index expressions of the object are static and have 
+   values that are within the range of the index constraint. 
+
+[Editor's note: The part of implicit dereference was missing here in the
+6.1.1 wording. Since a "null constraint" (that is, no constraint at all)
+is considered statically constrained, object of most access types would
+qualify for the original rule, which is not what we want.] 
 
-For other kinds of entities, a name statically names an entity if the name
-statically denotes the entity.
+For an entity other than an object, a name statically names an entity if 
+the name statically denotes the entity.
 
 Delete 6.1.1(24.2-5/5). [It is moved to 4.9 as above.]
 
@@ -384,5 +390,92 @@
   statically denotes the entity.
 
 but I'm no fan of "non"words.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Friday, March 6, 2020  9:23 AM
+
+...
+> Or we could use a parenthetical remark instead:
+> 
+> * a declare_expression whose body_expression is static and each of 
+>   whose declarations, if any, is either the declaration of a static 
+>   constant (which might be a stand-alone constant or a renaming 
+>   declaration) or is an object_renaming_declaration with a name that 
+>   statically names an array object;
+> 
+> The need for the AARM note (or the longer parenthetical remark) makes 
+> it less of an improvement than I originally hoped.
+
+I don't see the point of restricting it to array objects.  Presumably the 
+programmer will not waste time putting renames into a declare expression that 
+aren't going to be used in later declarations or in the expression.  So why 
+be picky here?  The key point is we don't want any declarations that require
+run-time elaboration, since that won't work for a static expression, and 
+"statically names" gives us that.  And who knows, some day we might have other
+sorts of static attributes.
+
+> 
+> ----
+> 
+> Another point I think came up elsewhere (but I haven't found where 
+> yet, it's definitely not in this thread).
+> 
+> That is, when we change 4.9(8) to:
+> 
+> * an attribute_reference whose prefix statically names a 
+>   statically constrained array object or array subtype, and whose 
+>   attribute_designator is First, Last, or Length, with an optional 
+>   dimension;
+> 
+> we now have wording that is talking about "statically names a ... 
+> array subtype". But the original definition of "statically names" only 
+> applies to objects.
+
+Yes, I noticed this in another (non-Ada-Comment) thread, and made essentially 
+the same suggestion you have below:
+
+"Another item that came to mind when looking at the definition of "statically 
+names" is that it only is defined for objects.  I would think we might want to
+use the term more generally, with it meaning "statically denotes" for things 
+other than objects, and have the additional ability to denote subcomponents for 
+objects." (24-Feb-2020, 4:31PM EST, "Pure_Barriers restriction relaxation")
+
+...
+> I suppose we 
+> could use something like:
+> 
+>  For nonobject entities, a name statically names an entity if the name  
+> statically denotes the entity.
+> 
+> but I'm no fan of "non"words.
+
+I am a nonfan as well. ;-)
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Friday, March 6, 2020  2:29 PM
+
+Humm. Maybe better than either would be:
+
+   For an entity that is not an object, a name statically names an entity if
+   the name statically denotes the entity.
+
+or:
+
+   For an entity other than an object, a name statically names an entity if 
+   the name statically denotes the entity.
+
+Rather than the vague "other kinds". Thoughts?
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Friday, March 6, 2020  2:47 PM
+
+Agreed. Either is better; I slightly prefer the second one ("other than an 
+object").
 
 ****************************************************************