CVS difference for 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
@@ -7,8 +8,9 @@
!subject Type_Invariants and tagged-type View Conversions
-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.
@@ -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 @@
+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.
Questions? Ask the ACAA Technical Agent