!standard 10.2.1(9/2) 07-01-12 AI05-0028-1/03 !standard 10.2.1(10.1/2) !standard 10.2.1(11.4/2) !standard 10.2.1(11.8/2) !class binding interpretation 06-11-13 !status work item 06-11-13 !status received 06-10-11 !priority Medium !difficulty Easy !qualifier Omission !subject Problems with preelaboration !summary TBD. !question 1 - 10.2.1(10.1/2) says that any formal private type or extension is assumed to not have preelaborable initialization. Surely this should not apply if the formal type has a pragma Preelaborable_Initialization. 2 - The same paragraph doesn't mention formal untagged derived types, but it seems like it should. These types may have a pragma P_I (see 10.2.1(11.8/2)) and since the actual type may have discriminants that differ from those of the ancestor of the formal, its preelaboration properties may differ too. 3 - I can't find a rule that would make the following illegal: generic type T is range <>; package G is pragma Preelaborate; end; package body G is C : constant T := T'First; end G; but it seems that an instance of G where T is not a static type cannot be preelaborable, so this case should be caught by the assume-the-worst rules in 10.2.1(10/2-10.4/2). 4 - 10.2.1(11.4/2) says that any override of the Initialize procedure is illegal. It would seem that an override with a null procedure should be legal. (The AI on pragma P_I was written long before we had null procedures.) 5 - More importantly, the property of having an override for the Initialize procedure violates privacy, as shown by the following example: package P is pragma Preelaborate; type T is new Ada.Finalization.Controlled with null record; private procedure Initialize (X : in out T); end P; It is not possible to apply pragma P_I to type P.T, so how are preelaborable clients of P supposed to know if they can declare an object of type P.T? 6 - In the case where pragma P_I is applied to a generic formal type extension, it would seem reasonable to require (on the generic) that the ancestor type have preelaborable initialization. Otherwise, we are left with a generic that is legal but cannot be instantiated, which is obnoxious. 7 - Ada 2005 dropped the "default initialized object" part of 10.2.1(9/2), because it was thought that it couldn't matter. Consider this example from text BA21002.A (case k): type Tag is tagged record C : My_Int := Func; D : Integer; end record; ... Tag1 : constant BA21002_0.Tag := (0, 10); -- OK. -- Declaration of a constant (j) (k). Type Tag does not have preelaborable initialization (because of the default expression). So 10.2.1(9/2) says that object Tag1 is illegal. But that is a nasty incompatibility with Ada 95, which (as the test shows) allowed this declaration. Was this incompatibility intended? (No.) !recommendation (See Summary.) !wording TBD. For question 7, replace the first sentence of 10.2.1(9/2) with: The creation of an object that is initialized by default of a type that does not have preelaborable initialization. !discussion TBD. --!corrigendum A.18.2(239/2) !ACATS test !appendix From: Pascal Leroy Date: Wednesday, October 11, 2006 3:35 AM I am implementing the new preelaboration and purity rules in 10.2.1, and I believe that some of the rules are incorrect or incomplete. 1 - 10.2.1(10.1/2) says that any formal private type or extension is assumed to not have preelaborable initialization. Surely this should not apply if the formal type has a pragma Preelaborable_Initialization. 2 - The same paragraph doesn't mention formal untagged derived types, but it seems like it should. These types may have a pragma P_I (see 10.2.1(11.8/2)) and since the actual type may have discriminants that differ from those of the ancestor of the formal, its preelaboration properties may differ too. 3 - I can't find a rule that would make the following illegal: generic type T is range <>; package G is pragma Preelaborate; end; package body G is C : constant T := T'First; end G; but it seems that an instance of G where T is not a static type cannot be preelaborable, so this case should be caught by the assume-the-worst rules in 10.2.1(10/2-10.4/2). 4 - 10.2.1(11.4/2) says that any override of the Initialize procedure is illegal. It would seem that an override with a null procedure should be legal. (The AI on pragma P_I was written long before we had null procedures.) 5 - More importantly, the property of having an override for the Initialize procedure violates privacy, as shown by the following example: package P is pragma Preelaborate; type T is new Ada.Finalization.Controlled with null record; private procedure Initialize (X : in out T); end P; It is not possible to apply pragma P_I to type P.T, so how are preelaborable clients of P supposed to know if they can declare an object of type P.T? 6 - In the case where pragma P_I is applied to a generic formal type extension, it would seem reasonable to require (on the generic) that the ancestor type have preelaborable initialization. Otherwise, we are left with a generic that is legal but cannot be instantiated, which is obnoxious. **************************************************************** From: Tucker Taft Date: Wednesday, October 11, 2006 7:01 AM > 2 - The same paragraph doesn't mention formal untagged derived types, but > it seems like it should. These types may have a pragma P_I (see > 10.2.1(11.8/2)) and since the actual type may have discriminants that > differ from those of the ancestor of the formal, its preelaboration > properties may differ too. Can you give an example of this? Untagged derived types cannot add discriminants, only effectively rename them. Is it that the *defaults* for the discriminants can change, and that's the issue for P_I? **************************************************************** From: Pascal Leroy Date: Wednesday, October 11, 2006 8:30 AM Yes, absolutely. For instance: type T1 (D1 : Integer := 3) is null record; type T2 (D2 : Integer := Some_Nasty_Function) is new T1(D1=>D2); Type T1 has obviously preelaborable initialization, and type T2 doesn't because the creation of a default-initialized object of type T2 calls Some_Nasty_Function. Now consider a formal type: generic type Formal is new T1; package G is end G; package body G is X : Formal; end G; We want to reject the generic body because if G were instantiated with T2 as an actual type, the elaboration of X would call Some_Nasty_Function. **************************************************************** From: Greg Gicca Date: Thursday, October 12, 2006 8:40 AM A question from the side lines... Can T1 and T2 be in different packages? If so how do you reject the generic since T2 may not have been compiled (or exist) when you compile G. A bind or link time error seems unreasonable. Maybe a novice question. **************************************************************** From: Randy Brukardt Date: Thursday, October 12, 2006 11:48 AM > Can T1 and T2 be in different packages? Yes, of course. > If so how do you reject the generic since T2 may not have been > compiled (or exist) when you compile G. A bind or link time > error seems unreasonable. Generally, in generic bodies Ada "assumes the worst". That is, if it is *possible* for some actual to make the body illegal, then the body is illegal even if there are many actuals that wouldn't make the body illegal. This makes generic body sharing possible, and preserves the contract model, among other things. So, in this case, since it is possible for there to be a type like T2 (whether or not it actually exists), the generic body should be illegal. Pascal's point is that we don't have such a rule, and we need one. > Maybe a novice question. No comment. ;-) **************************************************************** From: Randy Brukardt Date: Friday, January 12, 2007 1:32 PM We dropped the "default initialized object" part of 10.2.1(9/2), because we thought that it couldn't matter. I think we were wrong. Consider this example from text BA21002.A (case k): type Tag is tagged record C : My_Int := Func; D : Integer; end record; ... Tag1 : constant BA21002_0.Tag := (0, 10); -- OK. -- Declaration of a constant (j) (k). Type Tag does not have preelaborable initialization (because of the default expression). So 10.2.1(9/2) says that object Tag1 is illegal. But that's a nasty incompatibility with Ada 95 (as shown by this example), and there is no problem so long as the reason that type Tag does not have PInit is simply because of its default expressions (or its component types default expressions, ad nausum). I think we have to put back the "default initialized" wording. That would also cover <> in aggregates, the only way to write something other than default initialization for these sorts of types as a whole. The only alternative to that is to have two kinds of PInit, which sounds like heading down a rabbit hole to me. What do you think? **************************************************************** From: Tucker Taft Date: Friday, January 12, 2007 2:27 PM I agree, 10.2.1(9/2) should say: ... the creation of a default-initialized object (including a component) of a type that does not have preelaborable initialization. Or something like that. If you look at the wording in 10.2.1(11.3/2) there is similar wording, and perhaps we should just use that as a model. We clearly realized that default initialization was critical when deciding whether a component was preelaborable, so it makes sense to have the same criteria for deciding whether an object is preelaborable. So this is a corrigendum bug, I guess. **************************************************************** From: Randy Brukardt Date: Friday, January 12, 2007 2:54 PM > I agree, 10.2.1(9/2) should say: > > ... the creation of a default-initialized object (including > a component) of a type that does not have preelaborable > initialization. > > Or something like that. Well, it should include the new technical term initialized by default (which covers cases in allocators and aggregates as well). That wasn't done in the past 'cause there was no such term. But we surely want this to apply to aggregates and allocators. I also don't think we need the component wording: it's covered by the component rules for preelaborable initialization (PInit). That is, if there is a component that doesn't have PInit, then the type containing it cannot have PInit, either. That is part of the Ada 95 text that was moved to (11.1-11.5/2), but was left here for no reason. ... the creation of an object that is initialized by default of a type that does not have preelaborable initialization. > If you look at the wording in > 10.2.1(11.3/2) there is similar wording, and perhaps we > should just use that as a model. We clearly realized that > default initialization was critical when deciding whether > a component was preelaborable, so it makes sense to have > the same criteria for deciding whether an object is > preelaborable. Yes, and it makes even more sense because the wording was there in Ada 95, but someone convinced us we didn't need it. That often happens because we didn't understand all of the ramifications; it's always iffy to remove existing wording "because we don't need it". > So this is a corrigendum bug, I guess. Yes. I think we should just add it to AI05-0028, which is already discussing various preelaborable initialization bugs. I especially like that because that AI is not assigned to me, so I'll just add the question and get out of the way. ;-) ****************************************************************