CVS difference for ai05s/ai05-0110-1.txt
--- ai05s/ai05-0110-1.txt 2008/08/08 03:08:36 1.1
+++ ai05s/ai05-0110-1.txt 2008/10/25 04:53:14 1.2
@@ -142,3 +142,47 @@
****************************************************************
+From: Adam Beneschan
+Date: Friday, August 8, 2008 10:12 AM
+
+> Boiled down, the usual intepretation of this wording says that "If a
+> composite type and <some other stuff>, then the composite type is an
+> elementary type." I always thought that a type was either one or the
+> other (depending on its view and visibility on that view). This
+> wording only makes sense if it can be both at the same time.
+
+Hmmm... that's not how interpret it. 7.3.1(3/1) talks about composite
+types and seems to apply mostly to things like arrays of private
+types:
+
+ type T1 is private;
+ type T2 is array (natural range <>) of T1;
+
+I don't think this rule applies to my code snippet, and I didn't intend
+for it to. What the RM appears to be saying in 7.3.1(4/1) is, "There is a
+rule about derived types that looks just like 7.3.1(3/1) except that,
+in essence, you replace 'composite types whose component type is private'
+with 'derived types whose parent type is private'".
+Or, actually, replace "composite" with "derived" and "component type"
+with "parent type". So 7.3.1(4/1) doesn't really have anything to do with
+composite types. If 7.3.1(4/1) were written without the "corresponding rule"
+shorthand, I suppose it would look like:
+
+"For a derived type, the characteristics (see 7.3) of the type are determined
+in part by the characteristics of its parent type. At the place where the
+derived type is declared, the only characteristics of parent types used
+are those characteristics visible at that place. If later immediately
+within the declarative region in which the derived type is declared within
+the immediate scope of the derived type additional characteristics become
+visible for the parent type, then any corresponding characteristics become
+visible for the derived type. Any additional predefined operators are
+implicitly declared at that place."
+
+Maybe it should have been just been done that way---it would have been more
+verbose but perhaps less confusing.
+
+The point of my original question was: does this also apply to generic formal
+derived types?
+
+****************************************************************
+
Questions? Ask the ACAA Technical Agent