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

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

--- ai22s/ai22-0032-1.txt	2022/01/28 07:06:50	1.2
+++ ai22s/ai22-0032-1.txt	2022/02/04 03:54:02	1.3
@@ -1,12 +1,14 @@
-!standard 4.3(4/5)                                      22-01-27  AI22-0032-1/02
+!standard 4.3(4/5)                                      22-02-03  AI22-0032-1/03
 !standard 4.3.5(11/5)
 !class binding interpretation 22-01-26
+!status Corrigendum 1-2022 22-02-03
+!status ARG Approved 16-0-0  22-02-03
 !status work item 22-01-26
 !status received 21-11-09
 !priority Low
 !difficulty Easy
 !qualifier Omission
-!subject Abstract and classwide container aggregates
+!subject Abstract and class-wide container aggregates
 !summary
 
 Class-wide container aggregates are not allowed.
@@ -14,7 +16,7 @@
 If the container type of an Aggregate aspect is not abstract, none of the
 subprograms specified in the Aggregate aspect can be abstract.
 
-!question
+!issue
 
 (1) 4.3(4/5) disallows record and extension aggregates from being class-wide,
 but does not disallow class-wide aggregates of other kinds. Should container
@@ -38,12 +40,12 @@
 
 (2) Add after 4.3.5(11/5):
 
-  If the container type T is not abstract, then none of the names 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. 
+  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. 
 
-    AARM Ramification: Since the Aggregate aspect is nonoverriddable, this
+    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.
@@ -59,28 +61,20 @@
 
 It would be possible to support class-wide container aggregates, by treating
 them as tag-indeterminate and using the usual rules for tag-indeterminate
-functions to determine the tag for the anonynous object. Then, one would use
+functions to determine the tag for the anonymous object. Then, one would use
 dispatching calls on the subprograms (which are already required to be
 primitive, so no incompatibility would be introduced) to implement the
 aggregate. This seems like an extension rather than a fix, so we leave it
 for a future language update and disallow class-wide container aggregates for
 now.
 
-(2) The rules for abstract operations make it illegal for a non-abstract
-tagged to have any abstract operations. However, since the Aggregate aspect
-is allowed on any non-array type, abstract operations are possible if the
-type is not tagged. We surely do not want to have an aggregate calling
+(2) The rules for abstract operations make it illegal for a nonabstract
+tagged type to have any abstract operations. However, since the Aggregate
+aspect is allowed on any non-array type, abstract operations are possible if
+the type is not tagged. We surely do not want to have an aggregate calling
 abstract routines.
 
-One could argue that if following the Dynamic Semantics definition for an
-aggregate makes the aggregate illegal if that definition generates an illegal
-call. However, generally a Dynamic Semantics definition (even an equivalence,
-and container aggregates are not defined as an equivalence) does not imply an
-Legality Rules or Static Semantic rules, as these latter rules depend on the
-views of entities, while Dynamic Semantics rules almost never depend on the
-view.
-
-Moreover, we have a language design principle that if every use of some 
+We also have a language design principle that if every use of some 
 definition would be illegal, then the definition itself is illegal. (One
 example is a Pure generic unit; if no instantiation of the unit could be
 declared Pure, the generic unit is illegal.) This means we want the Aggregate
@@ -91,7 +85,7 @@
 from being used in an Aggregate aspect for a nonabstract type. Note that we
 do not need an additional rule to ban this for any derived type that inherits
 the Aggregate aspect, as this aspect is nonoverridable, and the Legality Rules
-associated with a nonoveriddable aspect are rechecked for each derived type
+associated with a nonoverridable aspect are rechecked for each derived type
 that inherits the aspect (by 13.1.1(18.3/5)).
 
 Note that it is OK to have abstract routines if the type itself is abstract;

Questions? Ask the ACAA Technical Agent