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

Differences between 1.1 and version 1.2
Log of other versions for file ai12s/ai12-0167-1.txt

--- ai12s/ai12-0167-1.txt	2015/06/18 00:51:09	1.1
+++ ai12s/ai12-0167-1.txt	2015/07/14 02:29:41	1.2
@@ -1,5 +1,6 @@
-!standard 7.3.2(9/4)                              15-06-17    AI12-0167-1/01
+!standard 7.3.2(9/4)                              15-07-10    AI12-0167-1/02
 !class ramification 15-06-17
+!status ARG Approved 11-0-1  15-06-27
 !status work item 15-06-17
 !status received 15-05-29
 !priority Low
@@ -7,8 +8,9 @@
 !subject Type_Invariants and tagged-type View Conversions
 !summary
 
-Modifying a component of type T of some other class-wide type which happens
-inside an abstraction for type T does not cause an invariant check.
+If an object of type T that is a component of a class-wide object is modified
+within the scope of the full view of type T, then there is no invariant check
+for T at that point.
 
 !question
 
@@ -58,7 +60,7 @@
 At the danger spot, we are changing Field using a local procedure which is
 allowed to violate the Type_Invariant that applies to its type, Has_Invariant.
 Unfortunately Field is a component of a class-wide object, and this will violate
-the general principal that components of a class-wide object should satisfy
+the general principle that components of a class-wide object should satisfy
 their invariants (as implied by 7.3.2(20.1/4)).
 
 Do we need an additional type invariant check to close this hole? (No.)
@@ -114,10 +116,24 @@
 
 !wording
 
-None suggested.
+Add after 7.3.2(20/3):
 
-[Editor's note: We could consider adding a user note and/or extending the
-existing AARM Ramification. I didn't try.]
+AARM To Be Honest:
+In all of the above, In all of the above, for a class-wide object, we are only
+referring to the parts of the specific root type of the class. We don't want
+the overhead of checking every class-wide object in case some future extension
+component *might* have type T (contrast this to finalization, where we do
+intend that overhead).
+
+Add after 7.3.2(20.a/4):
+
+Despite this model, if an object of type T that is a component of a class-wide
+object is modified within the scope of the full view of type T, then there is
+no invariant check for T at that point.
+
+Add to the end of 7.3.2(23.a/4):
+
+Similar holes exist for class-wide objects as discussed above.
 
 !discussion
 

Questions? Ask the ACAA Technical Agent