CVS difference for ai05s/ai05-0247-1.txt

--- ai05s/ai05-0247-1.txt	2011/06/03 02:42:13	1.11
+++ ai05s/ai05-0247-1.txt	2011/06/09 06:46:25	1.12
@@ -1,4 +1,4 @@
-!standard 6.1.1(0)                                    11-06-02  AI05-0247-1/10
+!standard 6.1.1(0)                                    11-06-09  AI05-0247-1/11
 !standard 7.3.2(0)
 !reference AI05-0145-2
 !class Amendment 11-03-21
@@ -302,7 +302,7 @@
   inherited from T2 does not fully conform to any class-wide precondition that
   applies P, then:
 
-  * If the type is abstract the implicit declared subprogram is *abstract*.
+  * If the type is abstract the implicitly declared subprogram is *abstract*.
 
   * Otherwise, the subprogram *requires overriding* and shall be overridden
     with a nonabstract subprogram.
@@ -345,6 +345,12 @@
     End AARM Ramification.
     [Editor's note: There is more on this topic in the !discussion.]
 
+    AARM Discussion: We use the term "requires overriding" here so that this
+    rule is taken into account when calculating visibility in 8.3; otherwise
+    we would have a mess when this routine is overridden. [Editor's Note:
+    8.3(12.2/3) to be specific, but we can't put paragraph numbers into AARM
+    notes.]
+
   If a renaming of a subprogram or entry S1 overrides an inherited subprogram
   S2, then the overriding is illegal unless each class-wide
   precondition that applies to S1 fully conforms to some
@@ -508,7 +514,7 @@
     and we need this rule for dispatching and access-to-subprogram calls
     anyway.]
 
-    We use the "for these purposes" part of the rule to include additional
+    We use the "for the purposes" part of the rule to include additional
     class-wide postconditions from those that apply to the original subprogram.
     This may happen if the operation is inherited from both a parent and a progenitor,
     and both the parent operation and progenitor operation have one or more
@@ -529,7 +535,7 @@
   or entry consists solely of checking the class-wide preconditions that apply
   to the denoted entity (not necessarily the one that is invoked).
 
-    AARM To Be Honest: The "for these purposes" rule mentioned in the previous
+    AARM To Be Honest: The "for the purposes" rule mentioned in the previous
     item also apply to class-wide preconditions of calls through
     access-to-subprogram values.
 
@@ -578,8 +584,8 @@
 
 Move 13.3.3 [from AI05-0146-1] to clause 7.3.2.
 
-In 7.3.2(8/3), change "Assertion_Policy" to "assertion policy" (as that is the
-term defined in 11.4.2).
+In 7.3.2(8/3) and 7.3.2(19/3), change "Assertion_Policy" to "assertion policy" (as
+that is the term defined in 11.4.2).
 
 Modify 7.3.2(18/3):
 
@@ -592,11 +598,11 @@
 in addition, if the subprogram is neither null nor abstract, the Type_Invariant(s)
 that apply to the parameter types of the invoked body are checked.
 
-    AARM Ramification: We use the "for these purposes" part of the rule to include
+    AARM Ramification: We use the "for the purposes" part of the rule to include
     additional Type_Invariant'Class checks from those that apply to the original
-    subprogram. This may happen if the operation is inherited from both a parent
-    and a progenitor, and both the parent operation and progenitor operation have
-    defined a Type_Invariant'Class.
+    subprogram. This may happen if the operation is inherited by a derived type
+    that has both a parent and a progenitor, and both the parent type and progenitor
+    type have defined a Type_Invariant'Class.
 
     For inherited concrete routines, we require the original Type_Invariant to be
     evaluated as well as the inherited Type_Invariant'Classes and the current type's
@@ -687,6 +693,11 @@
 
 Force a conflict; the real text is found in the conflict file.
 
+!corrigendum 7.3.2(0)
+
+@dinsc
+
+Force a conflict; the real text is found in the conflict file.
 
 !ACATS test