CVS difference for acs/ac-00215.txt
--- acs/ac-00215.txt 2011/04/01 03:47:47 1.2
+++ acs/ac-00215.txt 2011/04/09 06:04:01 1.3
@@ -181,11 +181,6 @@
***************************************************************
-From: Randy Brukardt
-Sent: Friday, January 28, 2011 11:12 PM
-
-***************************************************************
-
From: Adam Beneschan
Sent: Thursday, March 10, 2011 11:48 AM
@@ -205,6 +200,39 @@
***************************************************************
+From: Christoph Grein
+Sent: Friday, March 11, 2011 12:07 AM
+
+> My understanding has been that you take the components (including the
+> discriminants) of the ultimate ancestor type, followed by the
+> components of the type derived from that, and so on, until you get to
+> the type of the aggregate, and then select the needed components
+> keeping the same order. So a component of a parent type would come
+> before a discriminant of a child type.
+
+Just to oppose my understanding:
+
+You put down the components in the order you read them from left to right (resp.
+top down) in the type declaration: Aha, the type has a discriminant, so put this
+down. Next it's derived from some type, let's look there; go on like this until
+you come to the ultimate ancestor. Only then are you back at the type you
+started with and put down the components in the extension record.
+
+Both methods can be seen as intuitive. (I asked a collegue, and he arrived at
+Adam's sequence.)
+
+> But it doesn't seem like a good thing that two of us have such
+> different ideas about what the order should be.
+
+Yes, exactly.
+
+BTW: I have not yet had an opportunity to use streaming, but also there the
+discriminants come first (they have to or you couldn't construct the value). So,
+according to what you say, positional aggregates have a different order from
+streaming.
+
+***************************************************************
+
From: Adam Beneschan
Sent: Thursday, March 17, 2011 8:44 PM
@@ -245,6 +273,35 @@
for now, I'm going to try to make our compiler just reject positional
associations in cases involving variant parts and type extensions with
discriminants, and I doubt anyone will complain.
+
+***************************************************************
+
+From: Christoph Grein
+Sent: Friday, March 18, 2011 6:18 AM
+
+It seems that Rational follows my interpretation:
+
+package Pack is
+
+ type S (Disc: Boolean) is tagged record
+ F: Float;
+ case Disc is
+ when False => I: Integer;
+ when True => null;
+ end case;
+ end record;
+
+ type T (X: Boolean) is new S (X) with null record;
+
+ -- accepted
+ VT_F1: constant T := (True , 1.0);
+ VT_T1: constant T := (False, 1.0, 1);
+
+ -- rejected
+ VT_F2: constant T := (1.0, True);
+ VT_T2: constant T := (1.0, 1, False);
+
+end Pack;
***************************************************************
Questions? Ask the ACAA Technical Agent