CVS difference for ai12s/ai12-0065-1.txt

Differences between 1.3 and version 1.4
Log of other versions for file ai12s/ai12-0065-1.txt

--- ai12s/ai12-0065-1.txt	2013/06/11 01:01:49	1.3
+++ ai12s/ai12-0065-1.txt	2013/12/18 04:08:44	1.4
@@ -1,4 +1,4 @@
-!standard 7.3.1(5.2/3)                              13-05-08    AI12-0065-1/00
+!standard 7.3.1(5.2/3)                              13-11-16    AI12-0065-1/01
 !class binding interpretation 13-05-08
 !status work item 13-05-08
 !status received 13-01-26
@@ -9,7 +9,10 @@
 
 !summary
 
-** TBD.
+It is possible for a type T3 to be indirectly derived from a type T1 but
+inherit no characteristics from T1, because one of its ancestors, say T2,
+is declared at a point where the derivation from T1 is not visible.
+The wording in 7.3.1 should be clarified to explain this.
 
 !question
 
@@ -20,7 +23,6 @@
 
 Should this be clarified? (Yes.)
 
-
 !recommendation
 
 (See !summary.)
@@ -28,34 +30,74 @@
 !wording
 
 ** TBD.
-
-!discussion
+Modify 7.3.1(5.2/3, 5.a.*/3) as follows:
 
-The author of this question turns out to also have been the author of the
-paragraph and AARM notes in question. Which means that there is no real hope of
-figuring out what he was thinking. :-)
-
-It's clear that 7.3.1(5.2/3) is intended to be a clarification rather than
-the definition of anything; however, it doesn't seem to be clarifying anything,
-especially with its mention of "incomplete view".
-
-It appears to the editor that 7.3.1(5.1/3) sufficiently defines the normative
-wording. Perhaps it would be best to junk 7.3.1(5.2/3) or move its content into
-AARM notes. Moreover, the example in AARM 7.3.1(5.a.1-4/3) does not illustrate
-the situation described in 7.3.1(5.2/3) very well (there is no ancestor that
-is clearly not visible, although the described semantics are is true for the
-implicit type Root_Integer).
+   [redundant: [It]{Furthermore, it is possible for there to be places
+   where a derived type is [visibly a descendant of] {known to be
+   derived indirectly from} an ancestor type, but is not a descendant of
+   even a partial view of the ancestor type, because the parent of the
+   derived type is not visibly a descendant of the ancestor. In this
+   case, the derived type inherits no characteristics from that
+   ancestor, but nevertheless is within the derivation class of the
+   ancestor for the purposes of type conversion, the "covers"
+   relationship, and matching against a formal derived type.  In this
+   case the derived type is [considered to be] {effectively} a
+   descendant of an incomplete view of the ancestor. -- end redundant]
+
+  Discussion: Here is an example of this situation: 
+
+    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;  {-- T2 is *not* a descendant of Integer} 
+    end Q;
+
+    with Q;
+    package P.Child is
+        type T3 is new Q.T2;  -- 
+    private
+       {--  Here T3 is known to be indirectly derived from Integer, but 
+        --  inherits *no* characteristics from Integer, since T2 inherits
+        --  no characteristics from Integer.
+        --  However, we allow an explicit conversion of T3 to/from Integer.
+        --  Hence, T3 is effectively a descendant of an "incomplete" view of
+        --  Integer.}
+        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(W) + 1);   -- Legal: convert to Integer first
+    end P.Child;
+    
+----   
 
-Here's hoping that the stuckee for this AI can figure out better wording.
+!discussion
 
+Paragraph 7.3.1(5.2/3) was intended to be a clarification of 7.3.1(5.1/3), but
+its wording was sufficiently confusing that it only made matters worse.  We
+have tried to clarify the intent a bit.  
+
+Also, the AARM example was similarly intended to clarify things, but the
+mapping between the example and 5.2/3 was not clear, so again, things
+only became further muddled. Hopefully the added comments have helped
+explain how the example relates to 5.2/3.
 
 !ACATS Test
 
+No additional ACATS test needed.
+
 !ASIS
 
 No ASIS effect expected.
 
-
 !appendix
 
 From: Tucker Taft
@@ -212,3 +254,12 @@
 
 ****************************************************************
 
+From: Tucker Taft
+Sent: Saturday, November 16, 2013  11:31 PM
+
+Here is an attempt to clarify 7.3.1 a bit with regard to inheriting from a type
+while inheriting none of the characteristics of the type.
+
+[This is version /01 of the AI - Editor.]
+
+****************************************************************

Questions? Ask the ACAA Technical Agent