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

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

--- ai12s/ai12-0042-1.txt	2013/06/10 22:42:56	1.4
+++ ai12s/ai12-0042-1.txt	2013/07/18 00:11:33	1.5
@@ -1,4 +1,4 @@
-!standard 7.3.2(6/3)                                 13-06-09    AI12-0042-1/02
+!standard 7.3.2(6/3)                                 13-06-15    AI12-0042-1/03
 !class binding interpretation 12-11-29
 !status work item 12-11-29
 !status received 12-04-09
@@ -7,10 +7,10 @@
 !subject Type invariants cannot be inherited by non-private extensions
 !summary
 
-A record extension whose ancestor has a Type_Invariant'Class specified is
-illegal. Also, if a class-wide invariant applies to an ancestor, then
+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.
+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.
 
 !question
 
@@ -26,20 +26,31 @@
 
 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 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.
 
+
+In 7.3.2(18/3) replace
+
+   is visible outside the immediate scope of type T or overrides
+   an operation that is visible outside the immediate scope of T
+
+with
+
+   is dynamically callable (i.e. either directly or via a
+   dispatching call) from outside the immediate scope of T.
+   [In other words, that is visible outside of the immediate
+   scope of T or that overrides an operation inherited from one
+   that is dynamically callable from outside of the immediate
+   scope of T.]
+
 !discussion
 
+[This whole discussion is about an issue that we decided not to
+fix -- we need discussion about the issues that we *did* fix! - Editor.]
+
 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
@@ -74,6 +85,17 @@
 This rule is not incompatible with any existing (Ada 2005 or before)
 code; it only affects users of Type_Invariant'Class.
 
+---
+
+The wording for 7.3.2(18/3) addresses two issues:
+
+   1) Transitivity - we want to deal with overrides of overrides, and so on.
+
+   2) Given type T2 that extends T1, T2's operations never override T1's
+      operations, although they might override operations inherited from
+      T1's operations.
+
+
 !ACATS test
 
 An ACATS B-Test should be created to test this rule.
@@ -1222,6 +1244,42 @@
 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.]
+
+****************************************************************
+
+From: Steve Baird
+Sent: Saturday, June 15, 2013  6:24 AM
+
+My wording quibbles are orthogonal to the rest of the AI.
+I think we decided to kill the first paragraph of the wording changes we looked
+at today and keep the second, but in any case, here are *my* wording changes
+for this one.
+
+In 7.3.2(18/3) replace
+
+   is visible outside the immediate scope of type T or overrides
+   an operation that is visible outside the immediate scope of T
+
+with
+
+   is dynamically callable (i.e. either directly or via a
+   dispatching call) from outside the immediate scope of T.
+   [In other words, that is visible outside of the immediate
+   scope of T or that overrides an operation inherited from one
+   that is dynamically callable from outside of the immediate
+   scope of T.]
+
+Cheating here a little, recursively defining a new term without explicitly saying
+that that is what I am doing. It seemed the best way.
+
+The above addresses two separate issues:
+    1) Transitivity - we want to deal with overrides of
+       overrides, etc.
+
+    2) Given type T2 extends T1, T2's ops never override T1's ops,
+       although they might override ops inherited from T1's ops.
+
+[This is part of version /03 of this AI - Editor.]
 
 ****************************************************************
 

Questions? Ask the ACAA Technical Agent