CVS difference for ai22s/ai22-0005-1.txt

--- ai22s/ai22-0005-1.txt	2023/04/22 06:19:56	1.6
+++ ai22s/ai22-0005-1.txt	2023/09/30 03:58:28	1.7
@@ -122,7 +122,7 @@
    wording about the same declaration_list is redundant in that case.
 
    [Editor's note: Fix both of the AARM notes in AI22-0002-1 (After
-   AARM 4.1.6(3.b/3) and  AARM 5.5.1(8.a/3)).]
+   AARM 4.1.6(3.b/3) and AARM 5.5.1(8.a/3)).]
 
 I suspect this is what was meant to be written. The point is that the blanket
 rule makes the wording redundant in this particular case. We have the case
@@ -133,6 +133,72 @@
 
 Since AI22-0002-1 is WG 9 approved, I'll put this wording fix into AI22-0005-1
 (the AARM note AI). No ARG action is needed.
+
+****************************************************************
+
+From: Github issue #66, Tucker Taft
+Sent: September 7, 2023
+
+Section A.8.2, File Management, has useful descriptions of several operations
+applicable to almost all kinds of files. But these appear nowhere in the Index
+of the RM. That seems like an oversight.
+
+****************************************************************
+
+From: Github issue #66, Randy Brukardt
+Sent: September 28, 2023
+
+This isn't really a "bug report", since the index is non-normative. Rather, it
+is handled through the informal AARM update process. I've added this topic to
+AI22-0005-1 where all of the AARM fixes live, and closed this topic.
+
+****************************************************************
+
+From: Github issue #70, Steve Baird
+Sent: September 28, 2023
+
+We've currently got: [In AI22-0067-1 - Editor.]
+
+   Add after 4.3.3(31):
+
+      The nominal subtype of an array_aggregate (other than a subaggregate)
+      is constrained by the values defined for its bounds and those of any
+      subaggregates.
+
+For AARM, add after that:
+
+   To be honest:
+      If an array_aggregate has more than one subaggregate corresponding to
+      the same index, then the bounds of the first such subaggregate determine
+      the constraint of the nominal subtype of the array_aggregate
+      for that index.
+
+Given the current language definition (and, in particular, the RM's uses of
+"nominal subtype"), there does not appear to be any need to mention the
+case where some but not all of the subaggregates corresponding to a given
+index have static bounds. One could imagine something like "use static
+bounds if they are available; otherwise take the bounds from the first
+subaggregate" but this does not appear to be necessary.
+
+****************************************************************
+
+From: Github issue #70, Randy Brukardt
+Sent: September 29, 2023
+
+The proposed note seems like unjustified overspecification to me. We know that
+the bounds of all such subaggregates have to be the same, if not, Constraint_Error
+will be raised. If that happens, nothing that depends upon the nominal subtype
+can be executed. So, it doesn't matter which set of bounds is selected, and we
+should let the implementation pick whatever is convenient for it. Ergo, I think
+a better note would be something like:
+
+   Ramification: If an array_aggregate has more than one subaggregate
+   corresponding to the same index, then Constraint_Error will be raised unless
+   all of the bounds of such subaggregates are the same. If Constraint_Error
+   is raised, no code that could depend upon the details of the nominal subtype
+   of the aggregate could be executed. Therefore, the implementation can use
+   whichever such subaggregate is convenient to determine the bounds of the
+   nominal subtype.
 
 ****************************************************************