CVS difference for acs/ac-00173.txt

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

--- acs/ac-00173.txt	2009/06/02 01:00:44	1.1
+++ acs/ac-00173.txt	2009/06/02 06:23:00	1.2
@@ -76,3 +76,38 @@
 
 ****************************************************************
 
+From: Randy Brukardt
+Date: Friday, May 22, 2009  8:59 PM
+
+...
+> 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 
+> cause problems---I don't know.)
+
+Well, not all constants are really compile-time constant (see AI05-0054-2),
+so any of those that aren't really constant would have to be excluded. While
+the technique of getting a writable access via Initialize is not allowed -
+user-defined Initialize is not preelaboratable initialization (so controlled
+parts probably don't need a special exception), the Rosen trick does not
+appear to be prevented by preelaboration rules. That is, an immutably limited
+type can have preelaborable initialization. But any parts of a constant object
+that have immutably limited types would have to exclude the object from being
+used in preelaboration (since the values that they could have could not be
+known for certain at compile-time).
+
+That of course brings up a privacy issue - the fact that there are (or are
+not) components of an immutably limited type is not (in general) known for
+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.
+
+****************************************************************

Questions? Ask the ACAA Technical Agent