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

Differences between 1.7 and version 1.8
Log of other versions for file ai12s/ai12-0042-1.txt

--- ai12s/ai12-0042-1.txt	2013/11/05 00:06:44	1.7
+++ ai12s/ai12-0042-1.txt	2013/12/11 23:38:51	1.8
@@ -1,16 +1,18 @@
-!standard 7.3.2(6/3)                                 13-11-04    AI12-0042-1/05
+!standard 7.3.2(6/3)                                 13-11-16    AI12-0042-1/06
 !class binding interpretation 12-11-29
 !status work item 12-11-29
 !status received 12-04-09
 !priority Medium
 !difficulty Medium
-!subject Type invariants cannot be inherited by non-private extensions
+!subject Type invariants inherited by non-private extensions
 !summary
 
 If a class-wide invariant applies to an ancestor, then
 any private operation of the ancestor type that is visible at the point of the
-extension shall be overridden. In addition, the wording is clarified so that
-it is clear that "overrides" is transitive as to when checks are performed.
+extension shall be overridden. In addition, if a type invariant is inherited
+by a record extension, the type invariant is checked after any operation that
+corresponds to a visible operation of an ancestor to which the same invariant
+applies.
 
 !question
 
@@ -27,25 +29,50 @@
 Add after 7.3.2(6/3):
 
   If a private extension occurs at a point where a private operation of
-  some ancestor is inherited, and a Type_Invariant'Class expression
+  some ancestor is visible and inherited, and a Type_Invariant'Class expression
   applies to that ancestor, then the inherited operation shall be
   abstract or shall be overridden.
 
+Modify 7.3.2(16/3) as follows:
 
-In 7.3.2(18/3) replace
+   {If T is a private type or a private extension, then an} [An]
+   invariant is checked upon successful return from a call on any
+   subprogram or entry that:
+
+Modify 7.3.2(18/3) as follows:
 
    is visible outside the immediate scope of type T or overrides
-   an operation that is visible outside the immediate scope of T
+   an {inherited} operation that is visible outside the immediate scope
+   of T, and
 
-with
+Modify 7.3.2(16/3-19/3) as follows:
 
-    is *dynamically callable from outside the immediate scope of T*.
-    A subprogram is dynamically callable from outside the immediate
-    scope of T if it is is visible outside of the immediate
-    scope of T or if it overrides an operation inherited from one
-    that is dynamically callable from outside of the immediate
-    scope of T.
+   * An invariant is checked upon successful return from a call on any
+     subprogram or entry that:
+
+     * is declared within the immediate scope of type T (or by an
+       instance of a generic unit, and the generic is declared within the
+       immediate scope of type T), and
+
+     [* is visible outside the immediate scope of type T or overrides an
+        operation that is visible outside the immediate scope of T, and]
 
+      * has a result with a part of type T, or one or more parameters
+        with a part of type T, or an access to variable parameter whose
+        designated type has a part of type T[.]{,}
+
+     {* and either:
+
+        * T is a private type or a private extension and the subprogram
+          or entry is visible outside the immediate scope of type T or
+          overrides an inherited operation that is visible outside the
+          immediate scope of T, or
+
+        * T is a record extension and the subprogram or entry is a primitive
+          operation that corresponds to a visible operation of a private
+          or private extension ancestor to which the same (class-wide)
+          invariant applies.}
+
 !discussion
 
 This AI ended up very differently than how it started out.
@@ -79,27 +106,21 @@
        This is just to avoid surprising behavior, not because of any
        real definitional problem. IT also spares implementations from
        having to generate wrapper routines.
+
+   2)  In 7.3.2(18/3), the existing wording:
 
-   2)  In 7.3.2(18/3), the existing wording
          is visible outside the immediate scope of type T or overrides
          an operation that is visible outside the immediate scope of T
+
        was wrong in two ways and needed to be fixed up.
 
        First, this wording didn't correctly address the case of
-       an operation which overrides an operation which overrides
-       an operation which ... which is visible outside of the
-       immediate scope of T.
-       In order to get the recursion right, a new term was needed
-       (which could then be defined recursively). So the mouthful
-       "dynamically callable from outside the immediate scope of T"
-       was introduced.
+       a record extension.
 
        Second, the existing wording talked about overriding operations
        of a parent type. But a derived type never overrides operations
        of its parent type - instead, it may override implicitly-declared
-       operations that were inherited from operations of the parent type.
-       That's what the "inherited from one" part of the new wording is
-       about.
+       operations that were inherited from the parent type.
 
 !ACATS test
 
@@ -1291,8 +1312,8 @@
 From: Steve Baird
 Sent: Sunday, June 16, 2013  4:25 AM
 
-> Cheating here a little, recursively defining a new term without 
-> explicitly saying that that is what I am doing. It seemed the best 
+> Cheating here a little, recursively defining a new term without
+> explicitly saying that that is what I am doing. It seemed the best
 > way.
 
 Folks didn't like the cheating (understandably).
@@ -1313,3 +1334,13 @@
     scope of T.
 
 ****************************************************************
+
+From: Tucker Taft
+Sent: Saturday, November 16, 2013  10:40 PM
+
+Here is a rewrite of AI12-0042. [Editor's note: This is version /06 of the AI.]
+I reorganized a bit, and then handled the case of a private/private-extension
+type differently from a record extension.
+
+****************************************************************
+

Questions? Ask the ACAA Technical Agent