!standard 10.2.1(11.1/2) 09-06-01 AC95-00172/01 !class confirmation 09-06-01 !status received no action 09-06-01 !status received 09-02-13 !subject Generic formal objects and preelaborable generics !summary !appendix !topic Generic formal objects and preelaborable generics !reference RM 10.2.1, AI05-0028-1 !from Adam Beneschan 09-02-13 !discussion Although Ada 2005 has an assume-the-worst rule for how generic formal types are used in a generic body, in order for the generic to be preelaborable, it also lets you "get around" the rule by putting a Preelaborable_Initialization pragma in the generic formal part, to put restrictions on what types can be used when instnatiating the generic. Would it be useful to do something similar for generic formal IN objects? That is, since the assume-the-worst rule assumes that the actual for each generic formal object is nonstatic (10.2.1(10.3/2)), would it be useful to add a pragma to require that the acutal for a generic formal object be static? Then the generic formal object could be used in the generic body. This was motivated by some actual code; I believe the code is illegal and worked only because the error wasn't caught by an older version of the compiler, but I can understand what the programmer was trying to do: generic Number_Of_Indices : Natural; package Index_Manager is pragma Preelaborate; subtype Index_Type is Integer range 0 .. Number_Of_Indices - 1; ... end Index_Manager; package body Index_Manager is ... type Flag_Array is array (Index_Type) of Boolean; -- ERROR ... end Index_Manager; I believe that the line marked ERROR is illegal in a generic package designated as Preelaborable. However, if the actual for Number_Of_Indices were guaranteed to be static, then I believe the generic could be preelaborable and could be instantiated by a preelaborable library unit. I'm thinking of something like: generic Number_Of_Indices : Natural; pragma Must_Be_Static (Number_Of_Indices); package Index_Manager is ... Then, in any instance of Index_Manager, the actual for Number_Of_Indices would be required to be a static expression. I'm not sure if the definition of "static expression" in 4.9 could be changed to include such generic formal objects; if not, then perhaps the actual for Number_Of_Indices would be required to be a static expression, or a generic formal object to which Must_Be_Static applies, or (maybe) an expression which would be static if all generic formal objects to which Must_Be_Static applies are replaced by static expressions. Or do code-sharing implementations of generics make this idea unfeasible? **************************************************************** From: Randy Brukardt Date: Friday, February 13, 2009 3:41 PM ... > Or do code-sharing implementations of generics make this idea > unfeasible? Well, that depends if you expect Preelaborate to mean anything. While the idea is that there is no elaboration code, there is no way for the standard to require that. There is some IA that says "there should be little or no code executed...", which is washy-washy enough to include anything (plus you can just ignore the advice anyway). So it could be OK to allow some things to be preelaborable that cannot be implemented without elaboration code. But it surely would violate the intent of the preelaborable declaration. Surely for Janus/Ada there is no way for a generic formal parameter to be treated as static in the (shared) generic body. (I'm forever vigilant of anyone who tries to change that, accidentally or on purpose). Indeed, any generic that contained such a pragma could not be shared in any way (other than if all of the actuals were identical) and meet the intent of preelaboration. So I think this is a bad idea. **************************************************************** From: Bob Duff Date: Friday, February 13, 2009 4:40 PM ... > I'm thinking of something like: > > generic > Number_Of_Indices : Natural; > pragma Must_Be_Static (Number_Of_Indices); > package Index_Manager is ... And then I would like to be able to say (in Index_Manager): type T is range 1..Number_Of_Indices; type T is mod 2**Number_Of_Indices; for Blah'Size use Number_Of_Indices; or anything else that requires a static expression. I tend to agree with Randy -- this opens a can of worms, so let's not go there. BTW, didn't some early pre-83 version of Ada have something like this? Maybe I'm misremembering... ****************************************************************