CVS difference for ais/ai-00228.txt

Differences between 1.5 and version 1.6
Log of other versions for file ais/ai-00228.txt

--- ais/ai-00228.txt	2002/06/11 05:15:46	1.5
+++ ais/ai-00228.txt	2003/01/15 00:23:05	1.6
@@ -1,17 +1,18 @@
-!standard  3.09.3    (6)                             02-05-24  AI95-00228/02
-!class ramification 02-05-24
+!standard  3.09.3    (6)                             03-01-07  AI95-00228/03
+!standard  8.05.4    (5/1)
+!class binding interpretation 03-01-07
 !status work item 02-01-23
 !status received 00-04-10
 !priority Low
 !difficulty Medium
 !qualifier Clarification
-!subject Premature use of "shall be overridden" subprograms
+!subject Premature use of 'shall be overridden' subprograms
 
 !summary
 
 A subprogram which 'shall be overridden' in the sense of 3.9.3(6) is not
-subject to the restrictions that apply to an abstract subprogram. The 'shall be
-overriden' property doesn't apply to a renamed view.
+subject to the restrictions that apply to an abstract subprogram. It is
+illegal to rename a 'shall be overridden' subprogram.
 
 !question
 
@@ -24,7 +25,7 @@
 one in the AI:
 
    package Types is
-       type T is abstract tagged null record;
+       type T is tagged null record;
        function F return T;
    end Types;
 
@@ -32,79 +33,122 @@
    package Extensions is
        type E is new Types.T with null record;
        type A is access function return E;
-       X : A := F'Access; -- Legal? (Yes.)
+       procedure P (X : A := F'Access); -- Legal? (Yes.)
        function F return E;
    end Extensions;
 
-These are only some of the constructs that are problematic. Between the place
-where E is declared and the place where F is overridden, there are a number of
-constructs that could be used to ultimately call F. Are such constructs legal?
-(Yes.)
+Between the place where E is declared and the place where F is overridden,
+there are a number of constructs that could be used to reference F. Are such
+constructs legal? (Yes.)
 
-!response
+!recommendation
 
-The essence of the question revolves around the difference between "abstract"
-and "shall be overridden". AI95-00211 seems to have been written with the
+(See Summary.)
+
+!wording
+
+(See Corrigendum.)
+
+!discussion
+
+The essence of the question revolves around the difference between 'abstract'
+and 'shall be overridden'. AI95-00211 seems to have been written with the
 assumption that these terms were more or less synonymous, but in fact they are
 not. By definition, an abstract subprogram has no implementation, so we must
-prevent any contruct that could lead to non-dispatching calls to such a
-subprogram. On the other hand, the rules of RM95 3.9.3(6) ensure that an
-overrider will be provided for each "shall be overridden" subprogram, and that
-this overrider will not be abstract. So non-dispatching calls to such
-subprograms are fine, because we can guarantee that there exist a proper
-implementation.
+prevent any construct that could lead to non-dispatching calls to such a
+subprogram. On the other hand, the rules of 3.9.3(6) ensure that an
+overrider will be provided for each 'shall be overridden' subprogram, and that
+this overrider will not be abstract (assuming the type itself is not abstract).
+So non-dispatching calls to such subprograms are fine, because we can guarantee
+that there exists a proper implementation.
 
 To illustrate the difference, consider the following example, which is somewhat
 similar to the one in the question, but shows several levels of derivation:
 
     package P1 is
-        type T1 is abstract tagged ...;
+        type T1 is tagged ...;
         function F return T1;
-        procedure P (A : T1) is abstract;
     end P1;
 
     with P1;
     package P2 is
         type T2 is new P1.T1 with ...;
-        -- Inherits an F and a P which shall be overridden.
+        -- Inherits an F which shall be overridden.
+        -- May use F'Access in a default expression here.
     private
         function F return T2;
-        procedure P (A : T2);
     end P2;
 
     with P2;
     package P3 is
         type T3 is new P2.T2 with ...;
         -- Inherits an F which shall be overridden.
+        -- May use F'Access in a default expression here.
         function F return T3;
     end P3;
 
     with P1;
     package P4 is
         type T4 is new abstract P1.T1 with ...;
-        -- Inherits an F and a P which are abstract.
+        -- Inherits an F which is abstract.
+        -- F'Access is illegal.
     end P4;
 
-In package P2, T2 inherits two subprograms (F and P) which shall be overridden.
-In this instance the overrides appear in the private part, but at the point of
-the type declaration we know that an override is coming. So in the visible part
-of P2 it is legal to evaluate the attribute Access for F or P (note that most
-other usages of F or P are illegal in this example because they would freeze T2
-before its full definition). This wouldn't be true for abstract subprograms.
-
-In package P3, when we derive from P2.T2, there is no need to override the
-inherited P, because it has a perfectly good body (the one of the P declared in
-the private part of P2). On the other hand, P2.F being a function with a
-controlling result, it has to be overridden. Again, F'Access is legal in the
-specification of P3, even before the declaration of the overrider. Similarly, F
-may be called, used as a actual parameter to a generic instantiation, etc.
+In package P2, T2 inherits a function F which shall be overridden. In this
+instance the overrides appear in the private part, but at the point of the
+type declaration we know that an override is coming. So in the visible part
+of P2 it is legal to evaluate the attribute Access for F in a default
+expression (note that most other usages of F are illegal because they would
+freeze T2 before its full definition). This wouldn't be true for abstract
+subprograms.
+
+In package P3, when we derive from P2.T2, P2.F being a function with a
+controlling result, it has to be overridden. Again, F'Access is legal in a
+default expression in the specification of P3, even before the declaration
+of the overrider.
 
-In package P4, T4 is declared to be an abstract type, so the inherited F and P
-are abstract. They may or may not be overriden, but it is illegal, say, to
+In package P4, T4 is declared to be an abstract type, so the inherited F is
+abstract. It may or may not be overriden, but it is illegal, say, to
 evaluate F'Access before a non-abstract override has been given.
 
+A similar example can be constructed with an abstract root type and an
+inherited procedure:
+
+    package P1 is
+        type T1 is abstract tagged ...;
+        procedure P (A : T1) is abstract;
+    end P1;
+
+    with P1;
+    package P2 is
+        type T2 is new P1.T1 with ...;
+        -- Inherits a P which shall be overridden.
+        -- May use P'Access in a default expression here.
+    private
+        procedure P (A : T2);
+    end P2;
+
+    with P2;
+    package P3 is
+        type T3 is new P2.T2 with ...;
+        -- Inherits a perfectly good P.
+        -- May use P'Access anywhere.
+    end P3;
+
+    with P1;
+    package P4 is
+        type T4 is new abstract P1.T1 with ...;
+        -- Inherits a P which is abstract.
+    end P4;
+
+The inheritance mechanisms are similar in this second example, except that
+the procedure P inherited by P3.T3 does not have the 'shall be overridden'
+property. That's because the parent type, P2.T2, is guaranteed to have a
+non-abstract primitive procedure P (even though the overrider for P is
+declared in the private part).
+
 Based on this analysis, let's look again at AI95-00211. This AI deals with
-renamings of "shall be overridden" subprograms, as shown in the following
+renamings of 'shall be overridden' subprograms, as shown in the following
 example:
 
     package Types is
@@ -122,31 +166,34 @@
 
 Pr denotes a new view of P, and we know that P will ultimately be overridden.
 The overrider of P will actually provide a body for Pr, too, so there is no
-need for Pr to inherit the "shall be overridden" property. This is effectively
-repealing part of AI95-00211. [Author's note: a ramification repealed by
-another confirmation which says just the opposite; isn't it wonderful?]
+need for Pr to inherit the 'shall be overridden' property. However, an odd
+consequence of this analysis is that, although Pr occurs before the declaration
+of the override, it is not technically a squirrelling renaming in the sense of
+AARM 8.5.4(8.g).  This seems unnecessarily confusing.
+
+In order to avoid this oddity, it seems appropriate to make the renaming
+illegal (as stated in AI95-00211) but the logic for reaching that conclusion
+in AI95-00211 was incorrect, because of the confusion between 'abstract' and
+'shall be overridden'.
+
+!corrigendum 8.5.4(5/1)
+
+@dinsa
+The profile of a renaming-as-body shall be subtype-conformant with that of the
+renamed callable entity, and shall conform fully to that of the declaration it
+completes. If the renaming-as-body completes that declaration before the
+subprogram it declares is frozen, the profile shall be mode-conformant with
+that of the renamed callable entity and the subprogram it declares takes its
+convention from the renamed subprogram; otherwise, the profile shall be
+subtype-conformant with that of the renamed callable entity and the convention
+of the renamed subprogram shall not be Intrinsic. A renaming-as-body is illegal
+if the declaration occurs before the subprogram whose declaration it completes
+is frozen, and the renaming renames the subprogram itself, through one or more
+subprogram renaming declarations, none of whose subprograms has been frozen.
+@dinst
+If the @fa<@i<callable_entity>_name> of a renaming is a subprogram which
+shall be overridden (see 3.9.3), then the renaming is illegal.
 
-Another way to look at the same problem is to consider the case where the name
-being renamed is dynamic:
-
-    with Types;
-    package Extensions is
-        type E is new Types.T with ...;
-        -- Inherits a P which shall be overridden.
-        type A is access procedure (F : E);
-        X : A := P'Access;
-        procedure Pr (F : E) renames X.all;
-        procedure P (F : E);
-    end Extensions;
-
-If the attribute Access is legal, the renaming has to be legal, as there is no
-way that we can statically determine that X.all actually denotes a "shall be
-overridden" subprogram.
-
-An odd consequence of this analysis is that, although Pr occurs before the
-declaration of the override, it is not technically a squirelling renaming in
-the sense of AARM 8.5.4(8.g). [Author's note: Boy, I don't like this!]
-
 !ACATS test
 
 A B-Test should be created to test these rules, possibly added to an existing
@@ -611,6 +658,42 @@
 Approve intent of the AI: 7-0-0
 
 [Editor's note: this is complete reversal from earlier discussions.]
+
+*************************************************************
+
+From the minutes of the Bedford ARG meeting (October 2002):
+
+[Various typos omitted - ED]
+
+Tucker: How does freezing apply here? In the example which has P'Access, P is
+frozen, so it can't be overridden. It would have to be a default expression.
+Pascal wants to know where this rule is. After much argument, 13.14(4/1) is
+pointed out.
+
+There is some discussion about what compilers currently do with these examples.
+Through the wonders of modern technology (the laptop), several people try this
+example on their favorite compiler. Gary reports GNAT says: "prefix must be
+abstract". Tucker says that AdaMagic complains about freezing; as a default
+expression, it works; the squirreling rename says "fatal internal memory access
+error"!
+
+The example in the question is wrong, it should not have "abstract" in package
+Types. It would be useful to distinguish between the function example (non
+abstract type) and the procedure example (abstract type).
+
+The examples are screwed up, so the AI is sent back to Pascal to fix them.
+
+We discussed squirreling renames, and some members of the group are
+uncomfortable with the fact that this is not a squirreling rename, but it looks
+identical to it. That is different from the normal case. Randy says that he
+thinks the conclusion of AI-211 is correct (that the rename is illegal), but
+the logic to get to that conclusion is wrong. We probably need a binding
+interpretation to fix this.
+
+The group concludes that the best solution is to make these illegal. That
+should be done by inserting a new rule after 8.5.4(5): "if the
+callable_entity_name of a renaming is a must-be-overridden subprogram, then the
+renaming is illegal".
 
 *************************************************************
 

Questions? Ask the ACAA Technical Agent