Version 1.3 of ai05s/ai05-0028-1.txt

Unformatted version of ai05s/ai05-0028-1.txt version 1.3
Other versions for file ai05s/ai05-0028-1.txt

!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. ;-)

****************************************************************


Questions? Ask the ACAA Technical Agent