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

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

--- ai12s/ai12-0042-1.txt	2013/07/18 00:18:42	1.6
+++ ai12s/ai12-0042-1.txt	2013/11/05 00:06:44	1.7
@@ -1,4 +1,4 @@
-!standard 7.3.2(6/3)                                 13-06-16    AI12-0042-1/04
+!standard 7.3.2(6/3)                                 13-11-04    AI12-0042-1/05
 !class binding interpretation 12-11-29
 !status work item 12-11-29
 !status received 12-04-09
@@ -48,57 +48,62 @@
 
 !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.]
+This AI ended up very differently than how it started out.
 
-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?]
-
-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.
+A language issue was identified, thought to be a problem, explored, and
+found not to warrant any action after all. (This was the question of
+record extensions of types with class-wide invariants.)
+
+This sounds like it ought to yield a "no action" AI, but two minor points,
+largely unrelated to the main topic of the AI, were noticed along the way.
+After the dust had settled, these two guys were all that remained.
+
+The two minor points are:
+
+    1) If a private extension inherits from some ancestor both a
+       Type_Invariant'Class and a private operation, then we've
+       added a rule that the operation must be either overridden or
+       abstract. The point is that the class-wide Type_Invariant of
+       the ancestor didn't apply to the  original operation (because
+       it was a private operation) but it applies to the inherited
+       operation.
+
+       As a general rule, we require overriding (or abstractness)
+       in the case of inherited subprograms that have different
+       contracts (this includes pre/post-conditions as well as
+       type_invariants) than the "original" ancestor subprogram.
+       We don't want an implicitly-declared inherited subprogram
+       that performs checks that were not performed by the original
+       subprogram.
+
+       This is just to avoid surprising behavior, not because of any
+       real definitional problem. IT also spares implementations from
+       having to generate wrapper routines.
+
+   2)  In 7.3.2(18/3), the existing wording
+         is visible outside the immediate scope of type T or overrides
+         an operation that is visible outside the immediate scope of T
+       was wrong in two ways and needed to be fixed up.
+
+       First, this wording didn't correctly address the case of
+       an operation which overrides an operation which overrides
+       an operation which ... which is visible outside of the
+       immediate scope of T.
+       In order to get the recursion right, a new term was needed
+       (which could then be defined recursively). So the mouthful
+       "dynamically callable from outside the immediate scope of T"
+       was introduced.
+
+       Second, the existing wording talked about overriding operations
+       of a parent type. But a derived type never overrides operations
+       of its parent type - instead, it may override implicitly-declared
+       operations that were inherited from operations of the parent type.
+       That's what the "inherited from one" part of the new wording is
+       about.
 
-
 !ACATS test
 
-An ACATS B-Test should be created to test this rule.
+An ACATS B-Test should be created to test these rules.
 
 !appendix
 

Questions? Ask the ACAA Technical Agent