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

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

--- ai12s/ai12-0080-1.txt	2014/04/01 04:28:13	1.6
+++ ai12s/ai12-0080-1.txt	2014/05/09 19:25:52	1.7
@@ -1,4 +1,5 @@
-!standard 3.9.3(6/2)                                      14-03-31  AI05-0080-1/04
+!standard 3.9.3(6/2)                                      14-05-09  AI05-0080-1/05
+!standard 7.3.2(21/3)
 !standard A.18.26(29/3)
 !standard A.18.26(31/3)
 !standard B.1(50)
@@ -28,6 +29,9 @@
 
 4) Drop ".all" from the Edge renaming in the containers example.
 
+5) "Invariant" should be "Type_Invariant" in 7.3.2 as there is no such thing as
+an "Invariant policy".
+
 !question
 
 1) The following appears to be legal:
@@ -57,6 +61,9 @@
 generalized reference is itself a dereference; it's not a pointer that needs to be
 dereferenced. Should the ".all" be deleted? (Yes.)
 
+5) 7.3.2(21/3) talks about the "Invariant or Invariant'Class policy". But of
+course the policy is for Type_Invariant. Should this say "Type_Invariant"? (Yes.)
+
 !recommendation
 
 (See Summary.)
@@ -94,6 +101,13 @@
      E : Edge renames L(C)[.all];
 ...
 
+5) Modify 7.3.2(21/3):
+
+If performing checks is required by the [Invariant]{Type_Invariant} or
+[Invariant]{Type_Invariant}'Class assertion policies (see 11.4.2) in effect at
+ the point of corresponding aspect specification applicable to a given type,
+then the respective invariant expression is considered enabled.
+
 !discussion
 
 1) This problem was noted in the e-mail appendix to AI95-00391-1 (which
@@ -109,6 +123,9 @@
 4) Since a generalized reference is not (usually) a pointer, it can't (usually)
 be dereferenced. So ".all" doesn't make sense in this example.
 
+5) Since there is no such thing as an "Invariant" policy, this is a no-brainer
+correction.
+
 !corrigendum 3.9.3(6/2)
 
 @drepl
@@ -130,6 +147,19 @@
 subprogram need not be overridden for the formal type itself; a nonabstract
 version will necessarily be provided by the actual type.>
 
+!corrigendum 7.3.2(21/3)
+
+@drepl
+If performing checks is required by the Invariant or Invariant'Class assertion
+policies (see 11.4.2) in effect at the point of corresponding aspect
+specification applicable to a given type, then the respective invariant
+expression is considered @i<enabled>.
+@dby
+If performing checks is required by the Type_Invariant or Type_Invariant'Class
+ assertion policies (see 11.4.2) in effect at the point of corresponding aspect
+specification applicable to a given type, then the respective invariant
+expression is considered @i<enabled>.
+
 !corrigendum A.18.32(29/3)
 
 @drepl
@@ -298,5 +328,40 @@
 is an object (obtained via a dereference). At least the example A.18.32
 (paragraphs 29 and 31) are wrong this way, as are a lot of my other examples
 in e-mail and those I created for John in the Rationale.
+
+****************************************************************
+
+!topic Typo in 7.3.2(21)?
+!reference 7.3.2(21)
+!from Adam Beneschan 14-02-26
+!discussion
+
+7.3.2(21) says,
+
+    If performing checks is required by the Invariant or
+    Invariant'Class assertion policies (see 11.4.2) in effect at the
+    point of ...
+
+11.4.2, however, refers to Type_Invariant and Type_Invariant'Class, so this
+just looks like something where a name change was missed.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Wednesday, February 26, 2014  4:56 PM
+
+Since both changes are in the same AI, and that AI was one of the last ones to
+be introduced, long after the name change from Invariant to Type_Invariant, it
+looks more like your editor was asleep at the wheel. It's the sort of thing I
+detect all the time.
+
+In my defense, I probably was rushing to get the last minute changes done -
+these individual policies were invented at the Feb 2012 ARG meeting, the
+absolute last chance to change Ada 2012 before sending it into the
+standardization mill - and the month after that was frenzied to get the final
+document out ASAP with various last-minute issues getting wrapped up.
+
+Anyway, thanks for pointing this out. It'll get fixed (it's seemingly the only
+paragraph of 7.3.2 that previously didn't have an error).
 
 ****************************************************************

Questions? Ask the ACAA Technical Agent