Version 1.1 of acs/ac-00226.txt

Unformatted version of acs/ac-00226.txt version 1.1
Other versions for file acs/ac-00226.txt

!standard 10.2.1(5)          12-01-21 AC95-00226/00
!class confirmation 12-01-21
!status received no action 12-01-21
!status received 11-10-21
!subject Brain malfunction (are generic declarations preelaborable?)

!topic Are generic declarations preelaborable?
!reference 10.2.1
!from Adam Beneschan 11-10-21


This seems like it should be a settled question, but I can't find anywhere in
the RM that definitively answers this, so it seems to me that there may be some
missing rule (unless I just failed to find it when I searched).

ACATS test BA21A01 seems to say that generic declarations are preelaborable.
The comments say:

--      Check that each of the constructs above is legal within the visible
--      or private part of a generic library package declaration to which a
--      pragma Preelaborate applies ...

where the constructs are those which are no-nos in non-generic packages with
Preelaborate.  There's a test case:

   FObj: in FA21A00.My_Int;
package BA21A01_2 is
   pragma Preelaborate (BA21A01_2);
   Bool: Boolean := (FObj = 10);                                      -- OK.
                                      -- Primary that is a name of an object
                                      -- which is not a static expression.
end BA21A01_2;

which would violate 10.2.1(8) if it weren't generic.

But I don't see where the RM makes this legal.  10.2.1(11): "A pragma
Preelaborate ... is used to specify that a library unit is preelaborated ... The
declaration and body of a preelaborated library unit ... shall be
preelaborable."  So first we have to figure out whether the generic declaration
is preelaborable.  10.2.1(5) says, "An elaborable construct is preelaborable
unless its elaboration performs ...", so we have to figure out if the generic
declaration is elaborable.  This term isn't actually defined anywhere in the RM,
though.  There's a "To be honest" in the AARM, 3.1(11.g): "A construct is
elaborable is elaboration is defined for it."  12.1(10): "The elaboration of a
generic_declaration has no effect".  So does that mean elaboration is defined
(and defined to be empty), or not?  This isn't clear to me.  I think it could be
read either way.

But even if we assume that a generic declaration isn't elaborable, the RM still
doesn't say anything about whether it's preelaborable. 10.2.1(5-9.b) describes
when an elaborable construct is preelaborable, which we're assuming doesn't
apply.  10.2.1(10-10.4) describes when a generic body is preelaborable, which
also doesn't apply.  So where's the rule that tells us whether a non-elaborable
construct that isn't a generic body is preelaborable?  It seems to be implied
that everything else is preelaborable, but this seems to be at odds with how
mathematical definitions usually work.  (If we say "Everything with property A
has property X if P1 holds; everything with property B has property X if P2
holds", then if we have to make an assumption about things that don't have
properties A or B, our tendency is to assume that they *don't* have property X
since they're not mentioned at all.)

I think there's some wording missing.  Maybe adding something after
10.2.1(10.4) saying simply "A generic declaration is preelaborable" or "A
non-elaborable construct that is not a generic body is preelaborable" is needed.


From: Steve Baird
Sent: Friday, October 21, 2011  1:11 PM

I don't see a problem here.

> So does that
>> mean elaboration is defined (and defined to be empty), or not?  This
>> isn't clear to me.

The answer seems to me to clearly be "Yes".

>  I think it could be read either way.

I disagree.

It seems clear to me that a generic is an elaborable construct whose elaboration
does not perform any of the things that would disqualify it for


From: Adam Beneschan
Sent: Friday, October 21, 2011  1:27 PM

You're right.  Sorry about that, I had a brain malfunction.


Questions? Ask the ACAA Technical Agent