Version 1.1 of acs/ac-00065.txt

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

!standard 12.3(00)          03-07-31 AC95-00065/01
!class amendment 03-07-31
!status received no action 03-07-31
!status received 03-01-13
!subject Instantiation before package body is known to exist

!reference RM95-12.3
!from Dan Eilers 03-01-13

At the time a nested generic package is instantiated, the compiler
does not always know whether or not the package will have a body,
since pragma elaborate_body is only required for library packages.

This causes implementation difficulties in making sure that
if an unrequired body is later provided, its initialization code
will be called.

I propose that instantiating a nested generic package should "freeze"
the package such that if no body was required, then none would
subsequently be allowed.  Pragma elaborate_body could be used to
indicate that a body is required.

package P is
    package inner is     -- nested generic, no body required
    end inner;
    procedure p2;
end P;

with text_io;
package body P is

    procedure p2 is
       package new_inner is new inner;  -- instantiation before body seen
    end p2;

    package body inner is
       text_io.put_line("Hello");  -- how does this initialization get called?
    end inner;

end P;


From: Pascal Leroy
Sent: Tuesday, January 14, 2003  4:20 AM

As far as I understand this implementation difficulty has been with us since
circa A.D. 1983, and many implementations have managed to deal with it.

Your proposal would require existing code to change for no good reason: there
would be exactly zero benefit to the users, only some supposed simplification
for one implementer.  An incompatibility which is not motivated by an
improvement to the language is a no-no at this point in my opinion.


From: Dan Eilers
Sent: Tuesday, January 14, 2003 11:31 AM

I agree in principle that incompatibilities should be subject to
strict scrutiny.  However, I disagree with your assessment that there
would be "exactly zero benefit to the users".  This is a situation that
causes more than one compiler to silently generate incorrect code, which
puts the user in jeopardy of unbounded harm.

The user cannot rely on testing to assure that the generated code is correct,
since failure to execute initialization code can sometimes leave objects in
a normal state.

The user cannot rely on the ACATS to assure correct compiler behavior,
since ACATS includes no test for this situation, and the test that I have
submitted has not been incorporated.

The incompatibility is of the most harmless type.  It would be detected
at compile time, and fixable by the simple insertion of a pragma, which
can be completely automated.

The incompatibility is also believed to affect only a very small number
of applications.


From: Dan Eilers
Sent: Tuesday, January 14, 2003  1:14 PM

It does seem inconsistent to say that this case is not worth testing,
but on the other hand, insist that it's a compatibility problem.


Questions? Ask the ACAA Technical Agent