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

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

--- ai12s/ai12-0042-1.txt	2013/01/31 04:55:57	1.3
+++ ai12s/ai12-0042-1.txt	2013/06/10 22:42:56	1.4
@@ -1,4 +1,4 @@
-!standard 7.3.2(6/3)                                 12-11-29    AI12-0042-1/01
+!standard 7.3.2(6/3)                                 13-06-09    AI12-0042-1/02
 !class binding interpretation 12-11-29
 !status work item 12-11-29
 !status received 12-04-09
@@ -8,7 +8,9 @@
 !summary
 
 A record extension whose ancestor has a Type_Invariant'Class specified is
-illegal.
+illegal. Also, 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.
 
 !question
 
@@ -24,39 +26,53 @@
 
 Add after 7.3.2(6/3):
 
-If a Type_Invariant'Class expression applies to any ancestor of a type extension,
-the extension shall be a private extension or a record extension that is the
-completion of a private type or extension that has a Type_Invariant'Class that
-applies. In addition to the places where Legality Rules normally apply (see 12.3),
-this rule applies also in the private part of an instance of a generic unit.
+  If a Type_Invariant'Class expression applies to any ancestor of a type
+  extension, the extension shall be a private extension or a record
+  extension that is the completion of a private type or extension that
+  has a Type_Invariant'Class that applies. In addition to the places
+  where Legality Rules normally apply (see 12.3), this rule applies also
+  in the private part of an instance of a generic unit.
+
+  If a private extension occurs at a point where a private operation of
+  some ancestor is inherited, and a Type_Invariant'Class expression
+  applies to that ancestor, then the inherited operation shall be
+  abstract or shall be overridden.
 
 !discussion
 
-Type invariants were designed assuming that they only apply to private types
-declared in packages. That is necessary to have any sort of safety associated
-with them -- if they can apply to non-private types, pretty much anything can
-cause the invariant to be violated. On the other hand, for private types, nothing
-a client can do (short of unchecked programming or erroneous execution) can
-invalidate the invariant. That can only happen within the package, under the
-control of the package designer. [Truth in advertising - the package designer
-can introduce holes in rare cases; but these are easily avoided.]
-
-It's too early in the life of Ada 2012 to be abandoning the model of type invariants
-(or any other model, for that matter) [Note: this is being written in November 2012].
-Thus, it is best to make the simplest fix that preserves the model.
-
-This rule doesn't introduce a generic contract problems, as extensions from generic
-formal types are prohibited in generic bodies for other reasons (see 3.9.1(4)).
-
-The part about completions exists simply so that the completions of private extensions
-aren't illegal. (It also serves to prevent "hidden class-wide invariants", which would
-make enforcing the rule problematical.)
+Type invariants were designed assuming that they only apply to private
+types declared in packages. That is necessary to have any sort of safety
+associated with them -- if they can apply to non-private types, pretty
+much anything can cause the invariant to be violated. On the other hand,
+for private types, nothing a client can do (short of unchecked
+programming or erroneous execution) can invalidate the invariant. That
+can only happen within the package, under the control of the package
+designer. [Truth in advertising - the package designer can introduce
+holes in rare cases; but these are easily avoided.]
+
+It's too early in the life of Ada 2012 to be abandoning the model of
+type invariants (or any other model, for that matter) [Note: this is
+being written in November 2012]. Thus, it is best to make the simplest
+fix that preserves the model.
+
+This rule doesn't introduce a generic contract problem, as extensions
+from generic formal types are prohibited in generic bodies for other
+reasons (see 3.9.1(4)).
+
+The part about completions exists simply so that the completions of
+private extensions aren't illegal. (It also serves to prevent "hidden
+class-wide invariants", which would make enforcing the rule
+problematical.)
+
+We require inherited private operations to be overridden if not abstract,
+since when they become visible, the type invariant suddenly applies to them
+when it didn't before, and so they need to be overridden.
 
-[Should we define the term "class-wide invariant", it might make this wording a
-bit easier?]
+[Should we define the term "class-wide invariant", it might make this
+wording a bit easier?]
 
-This rule is not incompatible with any existing (Ada 2005 or before) code; it only
-affects users of Type_Invariant'Class.
+This rule is not incompatible with any existing (Ada 2005 or before)
+code; it only affects users of Type_Invariant'Class.
 
 !ACATS test
 
@@ -1194,6 +1210,18 @@
 If you think there is something specifically wrong with my example, please
 explain it. And if you now believe that one or more for the assertions made at
 the meeting are incorrect, please explain *that* so we can discuss it further.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Sunday, June  9, 2013  3:50 PM
+
+I added a new rule that requires a private operation of an ancestor with a
+class-wide type invariant to be overridden if it is inherited at the point of a
+private extension. This is because the class-wide invariant starts to apply to
+such an operation, when it didn't before, and the only way that avoids breaking
+privacy is if the operation is overridden. [This is version /02 of the
+AI - Editor.]
 
 ****************************************************************
 

Questions? Ask the ACAA Technical Agent