CVS difference for ais/ai-20218.txt

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

--- ais/ai-20218.txt	2003/06/18 00:12:25	1.3
+++ ais/ai-20218.txt	2003/07/15 20:41:11	1.4
@@ -993,5 +993,77 @@
 
 *************************************************************
 
+From: Randy Brukardt
+Sent: Tuesday, July 8, 2003  6:29 PM
+
+At the recent ARG meeting, we decided that there was no problem with
+overriding indicators for subprograms that are primitive for more than one
+type. The reason was that it was thought to be impossible to have such a
+routine that is overriding.
+
+I couldn't think of an example at the meeting, but I was dubious of that
+conclusion, as we had problems with such routines in Claw.
+
+I'm now fairly convinced that it is in fact possible to have such a routine
+that is overriding on one of the two types. Consider:
+
+package Foo is
+
+    type Root is tagged private;
+
+    type Counter is range 0 .. 10_000;
+
+    not overriding
+    procedure Add (Obj : in out Root; Cnt : in Counter);
+        -- Primitive on both Root and Counter.
+
+    type Child is new Root with private;
+
+    overriding --???
+    procedure Add (Obj : in out Child; Cnt : in Counter);
+        -- Primitive on both Child and Counter, and overriding (for Child).
+
+private
+    type Root is tagged record
+      Cnt : Counter := 0;
+    end record;
+
+    type Child is new Root with null record;
+end Foo;
+
+The second "Add" is overriding: the primitive Add is inherited (as it is
+declared before the declaration of Child); it is overriding (because it has
+the same profile as the inherited routine); and it is primitive for two
+types (because it is declared in the same package specification as Counter,
+so it is primitive for both Child and Counter.)
+
+(Aside: we did something like this in the root package of Claw, where the
+elementary type was "DWord". We didn't really want these routines to be
+primitive, but they are, and that meant they got inherited in some cases.)
+
+The overriding_indicator on the second Add is a problem. If you are thinking
+about the tagged types, you probably would expect it to be "overriding". But
+if you are thinking about "Counter", you would not expect it to be
+overriding.
+
+This case can't happen where both types are tagged types (Add would be
+illegal by 3.9.2(12) if Counter was tagged), but it certainly can happen in
+a case like this.
+
+My gut feeling is that we should simply define this to be overriding and not
+worry about it further. Comments?
+
+*************************************************************
+
+From: Gary Dismukes
+Sent: Tuesday, July 8, 2003  6:46 PM
+
+I have the same feeling, that it should be treated as overriding.
+After all, the main purpose of this feature is to use it for tagged
+primitives, so it doesn't seem reasonable for the untagged parameter
+to interfere with that use.
+
+*************************************************************
+
 
 

Questions? Ask the ACAA Technical Agent