CVS difference for ai05s/ai05-0090-1.txt

--- ai05s/ai05-0090-1.txt	2008/06/14 05:56:15	1.4
+++ ai05s/ai05-0090-1.txt	2008/06/14 06:58:29	1.5
@@ -1,4 +1,4 @@
-!standard 4.1.3(8-9.2/2)                                        08-06-13    AI05-0090-1/02
+!standard 4.1.3(8-9.2/2)                                        08-06-14    AI05-0090-1/03
 !standard 9.1(9.2/3)
 !standard 9.1(9.5/2)
 !standard 9.4(11.1/3)
@@ -28,36 +28,37 @@
 
    procedure Prim (S : in out Synch_Interface) is abstract;
 
-   task type Task_Type is new Synch_Interface with
+   procedure Yet_Another_Op (Obj : in out Synch_Inteface'Class);
+
+end Synch_Pkg;
+
+with Synch_Pkg;
+package Task_Pkg is
+   task type Task_Type is new Synch_Pkg.Synch_Interface with
       entry Prim;
       entry Other_Prim;
       entry Yet_Another_Op;
    end Task_Type;
 
-   package Nested_Pkg is
-      procedure Yet_Another_Op (Tsk : in out Task_Type);
-   end Nested_Pkg;
-
    -- Implicit declaration of overriding primitive (as per AI05-0042):
    -- procedure Prim (S : in out Task_Type);
 
    procedure Other_Prim (Tsk : in out Task_Type);  -- Legal? (No.)
 
-end Synch_Pkg;
+end Task_Pkg;
 
 ...
-
-T : Synch_Pkg.Task_Type;
 
-use Synch_Pkg.Nested_Pkg;
+T : Task_Pkg.Task_Type;
 
 ...
 
 T.Prim;            -- (1) Ambiguous? (No.)
 
-T.Other_Prim;      -- (2) Ambiguous? (The procedure declaration is illegal.)
+T.Other_Prim;      -- (2) Ambiguous? (Not possible; the procedure
+declaration is illegal.)
 
-T.Yet_Another_Op;  -- (2) Ambiguous? (Yes.)
+T.Yet_Another_Op;  -- (3) Ambiguous? (Yes.)
 
 
 The call to Prim at (1) using prefixed notation appears to be ambiguous,
@@ -96,14 +97,11 @@
 calls that use a prefixed view to be ambiguous between the wrapper
 subprogram and the implementing entry or protected operation. Note that
 it is illegal to declare an explicit primitive that has a prefixed view
-that is homographic with one of the type's operations. [Editor's musing:
-Probably should mention that it is possible for a class-wide operation
-to be ambiguous with such a prefix call, and in that case the prefix form
-cannot be used. So I'd suggest something like: "type's operations{, so
+that is homographic with one of the type's operations, so
 in normal cases it isn't possible to have an ambiguity in a prefix call.
 However, a class-wide operation of an ancestor type and declared in the
 same declarative list with the ancestor type is also considered, and that
-can make a call ambiguous.]
+can make a call ambiguous.
 
 Replace 9.1(9.5/2):
 
@@ -607,5 +605,47 @@
 declaration is illegal.)
 
 T.Yet_Another_Op;  -- (2) Ambiguous? (Yes.)
+
+****************************************************************
+
+From: Gary Dismukes
+Sent: Saturday, June 14, 2008  12:57 AM
+
+> I don't understand this. The operation in the nested package is not 
+> eligible to be a prefixed view, as it is not "declared *immediately* 
+> within the declarative region where an ancestor of T is declared". The 
+> use clause is irrelevant, that would make the operation directly visible as:
+>     Yet_Another_Op(T);
+> but that's not relevant here.
+
+You're right.  I was trying to illustrate a case like 2) that showed a
+legitimate ambiguity (since the call 2) turned out to be wrong because
+of the illegality) and ended up screwing up the example.
+
+> I think the only way to get an ambiguity is with a class-wide 
+> operation (which could be in an ancestor package):
+
+Yes, that would make more sense.  Thanks for the correction.
+
+I guess I'll be seeing this AI again...
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Saturday, June 14, 2008  1:57 AM
+
+...
+> > I think the only way to get an ambiguity is with a class-wide 
+> > operation (which could be in an ancestor package):
+> 
+> Yes, that would make more sense.  Thanks for the correction.
+
+I just noticed that there are two calls labeled (2) in the question.
+
+I'll replace the example with mine and fix the calls to have different numbers.
+ 
+> I guess I'll be seeing this AI again...
+
+Maybe, but not for this reason. But I'm didn't check the discussion very closely.
 
 ****************************************************************