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;
 
 ***************************************************************