CVS difference for acs/ac-00173.txt

Differences between 1.2 and version 1.3
Log of other versions for file acs/ac-00173.txt

--- acs/ac-00173.txt	2009/06/02 06:23:00	1.2
+++ acs/ac-00173.txt	2009/06/09 03:05:09	1.3
@@ -1,5 +1,5 @@
 !standard  10.2.1(5-9)                              09-06-01    AC95-00173/01
-!class confirmation 09-06-01
+!class Amendment 09-06-01
 !status received no action 09-06-01
 !status received 09-02-27
 !subject Preelaboration rules need loosening?
@@ -81,16 +81,16 @@
 
 ...
 > Actually, on further reflection, is there any reason for
-> 10.2.1(8) not to allow a name that denotes *any* constant?  
-> Any constant object that is named must be declared in another 
-> preelaborable package, and thus its value must satisfy the rules in 
-> 10.2.1(5-9).  So it seems that, at least, if a constant's (full) 
-> declaration is preelaborable, and another object declaration uses that 
-> constant's value as its own initial value, or as a subcomponent of the 
-> initial value, then that shouldn't prevent the second object 
-> declaration from preelaborable also.  (I realize that the constant 
-> name could be evaluated in other contexts besides as an initial value 
-> or subcomponent of an initial value of an object, and maybe those 
+> 10.2.1(8) not to allow a name that denotes *any* constant?
+> Any constant object that is named must be declared in another
+> preelaborable package, and thus its value must satisfy the rules in
+> 10.2.1(5-9).  So it seems that, at least, if a constant's (full)
+> declaration is preelaborable, and another object declaration uses that
+> constant's value as its own initial value, or as a subcomponent of the
+> initial value, then that shouldn't prevent the second object
+> declaration from preelaborable also.  (I realize that the constant
+> name could be evaluated in other contexts besides as an initial value
+> or subcomponent of an initial value of an object, and maybe those
 > cause problems---I don't know.)
 
 Well, not all constants are really compile-time constant (see AI05-0054-2),
@@ -109,5 +109,73 @@
 a deferred constant. Probably the best fix would be to allow pragma
 Preelaboratable_Initialization to be applied to constants as well. But of
 course that is a fairly substantial change, so I'm not sure it is worth it.
+
+****************************************************************
+
+From: Adam Beneschan
+Date: Wednesday, June 3, 2009  7:01 PM
+
+I'm not convinced this is a real concern.  To reconstruct the context (since
+both of us took some time to respond), I had a thought that 10.2.1(8) could be
+modified so that a preelaborable construct could refer to a _name_ that denotes
+any constant (in addition to allowing names that denote static expressions or
+discriminants of enclosing types).  Your response, if I understand correctly, is
+that this won't work because a constant could have a type with an access
+discriminant and still have preelaborable initialization; and since this allows
+the Rosen trick to be used, it's not guaranteed that if a construct refers to a
+constant, the compiler would know the value of the constant at compile time.  A
+more concrete example:
+
+   package Pack1 is
+      pragma Preelaborate(Pack1);
+      type Typ1 is limited record
+         ... some component that uses Typ1'access as a discriminant
+         F1 : Integer;
+      end record;
+      Const1 : constant Typ1 := <something>;
+   end Pack1;
+
+   with Pack1;
+   package Pack2 is
+      pragma Preelaborate(Pack2);
+      type Typ2 is limited record
+         ...
+         F2 : Integer;
+         ...
+      end record;
+      Const2 : constant Typ2 := (..., F2 => Pack1.Const1.F1, ...);
+   end Pack2;
+
+My "proposal" (still just a thought) would be to allow the reference to
+Pack1.Const1 in the preelaborable package.  You're saying that the compiler
+can't know for certain what the value of Pack1.Const1.F1 is since it could have
+been modified via the Rosen trick.  Am I understanding you corrctly?
+
+If I am, I think this is wrong, because I don't see any way that the constant
+could be modified.  Any elaboration that takes place before the evaluation of
+Const2's initial expression must be in a preelaborable package; and since
+elaborations in preelaborable packages may not contain statements or subprogram
+calls (other than to static functions), I don't see how it's possible for any
+code that uses the Rosen trick to be executed.  So it appears to me that, even
+though later code *could* possibly change the value of Const1.F1---assuming this
+is doable legally, which I haven't looked into---it isn't possible to change
+Const1.F1 before it's used to initialize Const2, so the compiler *does* know
+what the value is.
+
+If there's some more complex example that breaks this, I can't think of one.  In
+any event, the fact that GNAT's runtime tried to use this illegal construct (not
+caught by their compiler) is evidence that it would be useful to have *some* way
+to do this legally, and I'm hopeful that the idea isn't sunk by some obscure and
+probably pathological example.
+
+P.S. Constants that have Import applied to them could be a problem, though.
+
+****************************************************************
+
+From: Randy Brukardt
+Date: Monday, June 8, 2009  10:04 PM
+
+For the record, it wasn't sunk by an obscure example. It simply was judged "not
+important enough".
 
 ****************************************************************

Questions? Ask the ACAA Technical Agent