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

Differences between 1.3 and version 1.4
Log of other versions for file ai22s/ai22-0032-1.txt

--- ai22s/ai22-0032-1.txt	2022/02/04 03:54:02	1.3
+++ ai22s/ai22-0032-1.txt	2022/02/05 05:28:19	1.4
@@ -1,4 +1,4 @@
-!standard 4.3(4/5)                                      22-02-03  AI22-0032-1/03
+!standard 4.3(4/5)                                      22-02-04  AI22-0032-1/04
 !standard 4.3.5(11/5)
 !class binding interpretation 22-01-26
 !status Corrigendum 1-2022 22-02-03
@@ -41,15 +41,20 @@
 (2) Add after 4.3.5(11/5):
 
   If the container type T is not abstract, then none of the subprograms 
-  specified in the Aggregate aspect for T shall be abstract.  In addition
-  to the places where Legality Rules normally apply (see 12.3), these rules
-  apply also in the private part of an instance of a generic unit. 
+  specified in the Aggregate aspect for T shall be abstract.
 
     AARM Ramification: Since the Aggregate aspect is nonoverridable, this
     rule is rechecked on any derived type that inherits an Aggregate aspect.
-    This rule also has to be rechecked in instances, in case an actual type 
-    for an abstract formal type is not abstract.
 
+  In addition to the places where Legality Rules normally apply (see 12.3),
+  these rules apply also in the private part of an instance of a generic unit. 
+
+    AARM Ramification: The first Legality Rule has to be rechecked in
+    instances, if a type with an Aggregate aspect is derived from a formal
+    private type, in case the actual type for the private type is an array
+    type. The last Legality Rule has to be rechecked in instances, in case
+    an actual type for an abstract formal type is not abstract.
+
 !discussion
 
 (1) 4.3(4) originally disallowed all aggregates from being class-wide. It was
@@ -93,11 +98,41 @@
 by 3.9.3(8/5)). It's unclear if this would be a useful construct, but since
 there is no semantic problem, there seems to be no reason to ban it.
 
+!corrigendum 4.3(4/5)
+
+@drepl
+A @fa<record_aggregate> or @fa<extension_aggregate> shall not be of a
+class-wide type.
+@dby
+A @fa<record_aggregate>, @fa<extension_aggregate>, or @fa<container_aggregate>
+shall not be of a class-wide type.
+
+!corrigendum 4.3.5(11/5)
+
+@dinsa
+For an Aggregate aspect, the key type of Assign_Indexed shall be the same 
+type as that of the parameters of New_Indexed. Additionally, if both 
+Add_Unnamed and Assign_Indexed are specified, the final parameters shall 
+be of the same type @emdash the element type of the container type.
+@dinst
+If the container type @i<T> is not abstract, then none of the subprograms 
+specified in the Aggregate aspect for @i<T> shall be abstract.
+
+In addition to the places where Legality Rules normally apply (see 12.3),
+these rules apply also in the private part of an instance of a generic unit. 
+
 !ACATS test
 
 ACATS B-Test(s) should check that both of these rules are enforced (and in the
 case of the abstract routines, also are enforced for [untagged] derived types).
 
 !appendix
+
+From: The Editor - February 4th, 2022
+
+I happened to notice that the first Legality Rule of 4.3.5 also could need
+rechecking in an instance. Therefore, I put the generic boilerplate into a
+separate paragraph and split and updated the AARM note appropriately. Consider
+this my editorial review.
 
 ****************************************************************

Questions? Ask the ACAA Technical Agent