CVS difference for 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