CVS difference for ais/ai-00239.txt

Differences between 1.3 and version 1.4
Log of other versions for file ais/ai-00239.txt

--- ais/ai-00239.txt	2000/10/05 02:47:30	1.3
+++ ais/ai-00239.txt	2004/04/06 22:19:44	1.4
@@ -1,4 +1,4 @@
-!standard 3.9.2  (18)                                  00-07-20  AI95-00239/01
+!standard 3.9.2  (18)                                  04-04-02  AI95-00239/02
 !class binding interpretation 00-07-20
 !status work item 00-07-20
 !status received 00-07-20
@@ -32,7 +32,7 @@
     type T2 is new Pkg1.T1 with null record;
 
     -- Inherits:
-    --procedure Pa (P : in T2 := Pkg1.Fa);
+    -- procedure Pa (P : in T2 := Pkg1.Fa);
 
     function Fa return T2;
 
@@ -45,13 +45,25 @@
 
 Which Fa is called as the default expression of Pkg2.Pa? (Pkg2.Fa)
 
-The inherited specification of Pkg2.Pa is
+!recommendation
+
+(See summary.)
+
+!wording
 
-   procedure Pa (P : in T2 := Pkg1.Fa);
+Replace 3.9.2(18) by:
 
-because the default expression is inherited unchanged, by 3.4(22). The
-possibility of type mismatch is mentioned and expected.
+If the call has a controlling result and is itself a (possibly parenthesized or
+qualified) controlling operand of an enclosing call on a dispatching operation
+of a descendant of type T, then its controlling tag value is determined by the
+controlling tag value of this enclosing call;
 
+!discussion
+
+In inherited specification of Pkg2.Pa, the default expression is inherited
+unchanged, by 3.4(22). The possibility of type mismatch is mentioned and
+expected.
+
 3.9.2(14-19) say:
 
 For the execution of a call on a dispatching operation of a type T, the
@@ -91,29 +103,11 @@
 type T2. Thus, the tag of Pkg1.Fa is static determined to be T1. Similarly, the
 tag of the enclosing call is statically determined to be T2.
 
-This seems weird; is this the intent? (No.)
-
-!recommendation
-
-(See summary.)
-
-!wording
-
-Something has to be changed in 3.9.2(18). (Based on the quality of the summary,
-I don't think I should try to word this! But we have to do it to understand the
-ramifications, as this is likely to silently change the behavior of user code.
-[Many existing compilers implement the standard literally, which is shown below
-to cause significant problems.])
-
-!discussion
-
 AARM 3.9(1.g) notes that there is a general principle that the subprograms
 called for a statically tagged call are the same as those that would be
-called in a dispatching call.
+called in a dispatching call. The literal reading of the standard violates this
+principle in this example.
 
-The literal reading of the standard violates this principle in the example
-given above.
-
 Note that it is impossible to create such a call explicitly, as the type
 mismatch would make the call illegal.
 
@@ -128,7 +122,7 @@
     end record;
 
     -- Inherits:
-    --procedure Pa (P : in T3 := Pkg1.Fa);
+    -- procedure Pa (P : in T3 := Pkg1.Fa);
 
     function Fa return T3;
 
@@ -139,8 +133,34 @@
 Now, the call Pkg3.Pa would be made with a parameter of type T1! The body of
 Pkg3.Pa could then attempt to read a non-existent P.New_Component.
 
+The root of the problem is 3.9.2(18), which assumes that the only contexts that
+can control dispatching of a function with a controlling result of type T are
+those that involve controlling operands of the same type T. That's true for
+code that the user can write explicitly because if the two types differ there
+is an illegality and the dynamic semantics are irrelevant.
+
+Here, as noted above, we have code that the user could not write explicitly. It
+is obvious that we want dispatching to happen, so we must relax 3.9.2(18) a
+bit. The phrase that requires the two types to match is "of type T". We are
+changing it to "of a descendant of type T". This is safe, because if the type
+of the parameter is descended from the type of the function result, it is
+guaranteed to inherit or override the function, and this ensures that there
+will be an appropriate body to dispatch to. Note that abstract functions are
+not an issue here because the call to the function is a dispatching call, so it
+is guaranteed to always land on an concrete body.
 
 !corrigendum  3.9.2(18)
+
+@drepl
+@xbullet<If the call has a controlling result and is itself a (possibly
+parenthesized or qualified) controlling operand of an enclosing call on a
+dispatching operation of type @i<T>, then its controlling tag value is
+determined by the controlling tag value of this enclosing call;>
+@dby
+@xbullet<If the call has a controlling result and is itself a (possibly
+parenthesized or qualified) controlling operand of an enclosing call on a
+dispatching operation of a descendant of type @i<T>, then its controlling tag
+value is determined by the controlling tag value of this enclosing call;>
 
 !ACATS test
 

Questions? Ask the ACAA Technical Agent