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

Differences between 1.14 and version 1.15
Log of other versions for file ai05s/ai05-0115-1.txt

--- ai05s/ai05-0115-1.txt	2011/04/22 03:08:51	1.14
+++ ai05s/ai05-0115-1.txt	2011/04/22 03:17:04	1.15
@@ -1,4 +1,4 @@
-!standard 4.3.2(5/2)                                  11-04-19  AI05-0115-1/09
+!standard 4.3.2(5/2)                                  11-04-20  AI05-0115-1/10
 !standard 7.3.1(5/1)
 !class binding interpretation 08-10-15
 !status work item 08-10-15
@@ -22,6 +22,9 @@
 two types is visible, even if one of the ancestors in the chain
 might not have visibility on all of the intermediate derivations.
 
+For type conversion, we don't consider the root numeric types when
+looking for a common ancestor.
+
 !question
 
 Consider the following:
@@ -129,6 +132,19 @@
   of the ancestor type from which the type is descended (see 7.3.1)
   shall not have unknown discriminants.}
 
+Modify 4.6(21/2):
+
+  If there is a type {(other than a root numeric type)} that is an
+  ancestor of both the target type and the operand type, or both types
+  are class-wide types, then at least one of the following rules shall
+  apply:
+
+Modify 4.6(24/2):
+
+  If there is no type {(other than a root numeric type)} that is the
+  ancestor of both the target type and the operand type, and they are
+  not both class-wide types, one of the following rules shall apply:
+
 Add after 7.3.1(5/1):
 
   A type is a /descendant/ of the full view of some ancestor of its
@@ -153,26 +169,30 @@
   incomplete view of the ancestor.]
 
   [AARM Discussion:  Here is an example of this situation:
-     package P is
-        type T is private;
-     private
-        type T is new Integer;
-        C : constant T := 42;
-     end P;
-
-     with P;
-     package Q is
-         type T2 is new P.T;
-     end Q;
-
-     with Q;
-     package P.Child is
-         type T3 is new Q.T2;
-     private
-         X : T3 := T3(P.C);  -- legal: conversion allowed
-         Y : T3 := X + 1;   -- error: no visible "+" operator
-     end P.Child;
-
+	 package P is
+	    type T is private;
+	    C : constant T;
+	 private
+	    type T is new Integer;
+	    C : constant T := 42;
+	 end P;
+
+	 with P;
+	 package Q is
+	     type T2 is new P.T;
+	 end Q;
+
+	 with Q;
+	 package P.Child is
+	     type T3 is new Q.T2;
+	 private
+	     Int : Integer := 52;
+	     V : T3 := T3(P.C);  -- legal: conversion allowed
+	     W : T3 := T3(Int);  -- legal: conversion allowed
+	     X : T3 := T3(42);   -- error: T3 is not a numeric type
+	     Y : T3 := X + 1;    -- error: no visible "+" operator
+	     Z : T3 := T3(Integer(X) + 1);   -- legal: convert to Int first
+	 end P.Child;
    ]
 
 !discussion
@@ -257,7 +277,7 @@
   information could be made in determining legality.
 
 We worried that an altered definition of descendant might create
-incompatibilities, and there seemed no definition concern with allowing
+incompatibilities, and there seemed no definitional concern with allowing
 conversions, matching, etc., to be as generous as possible. So long as
 it *inherits* characteristics only from ancestors from which its parent
 inherits characteristics, we felt there would be no problem. Effectively
@@ -266,6 +286,11 @@
 ability to convert (explicitly or implicitly due to being "covered") or
 to pass as an actual in a generic instantiation.
 
+We altered the rules on type conversions slightly for the "common ancestor"
+case (paras 21-24), so that a root numeric type is not allowed to be the
+only common ancestor for these rules to apply. This seems to conform
+with existing practice.
+
 See the !example section below for more detailed discussion of how this
 view-related definition of ancestor relates to the original question,
 namely the legality of various aggregates.
@@ -2806,5 +2831,77 @@
           X : T3 := T3(P.C);  -- legal: conversion allowed
           Y : T3 := X + 1;   -- error: no visible "+" operator
       end P.Child;
+
+****************************************************************
+
+From: Ed Schonberg
+Sent: Tuesday, April 19, 2011  8:38 PM
+
+OK, this is unobjectionable.  It's the sudden "numericness" of T3 that had
+bothered me in the previous example.
+
+****************************************************************
+
+From: Jean-Pierre Rosen
+Sent: Tuesday, April 19, 2011  11:54 PM
+
+> X : T3 := T3(P.C); -- legal: conversion allowed Y : T3 := X + 1; --
+> error: no visible "+" operator end P.Child;
+
+To be perfectly clear, I suggest adding (with a use clause on P):
+Z: T3 := T3 (T(X) + 1); -- legal
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Wednesday, April 20, 2011  8:18 AM
+
+Actually, the second example I sent out did not prove anything.  Of course you
+can convert to type T, since the derivation from T to T3 is out in the open.
+The real question was whether you could convert all the way to Integer, which is
+not a "known" ancestor as far as T2 is concerned.
+
+
+  package P is
+     type T is private;
+     C : constant T;
+  private
+     type T is new Integer;
+     C : constant T := 42;
+  end P;
+
+  with P;
+  package Q is
+      type T2 is new P.T;
+  end Q;
+
+  with Q;
+  package P.Child is
+      type T3 is new Q.T2;
+  private
+      Int : Integer := 52;
+      V : T3 := T3(P.C);  -- legal: conversion allowed
+      W : T3 := T3(Int);  -- legal: conversion allowed
+      X : T3 := T3(42);  -- error: T3 is not a numeric type
+      Y : T3 := X + 1;   -- error: no visible "+" operator
+      Z : T3 := T3(Integer(X) + 1);   -- legal: convert to Int first
+  end P.Child;
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Wednesday, April 20, 2011  1:50 PM
+
+OK, here we go again.  This has the newer example. [This is version /10 of
+the AI - Editor.]
+
+This also makes some slight adjustments to the rules on type conversion based on
+having a common ancestor.  The adjustment requires that the common ancestor be
+something other than a root numeric type.  Being allowed to use numeric literals
+seems like a characteristic that should be inherited like other characteristics.
+We don't want the fact that universal-integer shares a common ancestor
+(root-integer) with all descendants of Integer to allow integer literals to be
+used with types that are "secretly" derived from Integer, like the example given
+in the AI.
 
 ****************************************************************

Questions? Ask the ACAA Technical Agent