!standard  12.3(12)                               12-06-06    AC95-00235/00
!class confirmation 12-06-06
!status received no action 12-06-06
!status received 12-05-16
!subject Allow subprogram declaration to be completed by instantiation
!summary

!appendix

From: Adam Beneschan
Sent: Wednesday, May 16, 2012  8:38 PM

!topic Allow subprogram declaration to be completed by instantiation
!reference 12.3(12), 6.1(20)
!from Adam Beneschan 12-05-16
!discussion

Someone posted today on comp.lang.ada trying to figure out why this wouldn't
compile.  I don't think this is the first poster to get tripped up by this.  The
code was something like

    package Foo is
      procedure P;
    end Foo;

    package body Foo is
      procedure P is new Some_Generic_Procedure;
    end Foo;

I think that 12.3(12) is the only thing that makes this illegal; it says that
the instantiation is "equivalent to the instance declaration (a
package_declaration or subprogram_declaration) immediately followed by the
instance body, both at the place of the instantiation", and it's illegal to have
two declarations for the same procedure.

This is easily fixable with a renaming-as-body.  However, I think it's possible
to change the language easily without having any other serious impact; not
allowing the above example seems kind of clunky, especially to
non-language-lawyers, and I think if it can be fixed without causing any other
problems, it should be considered.  If this does impact the semantics in any
other way, or is difficult to implement, then it's probably not worthwhile.  I
don't think it would be difficult to implement, though, and I don't see any
other issues.

Change 12.3(12):

A generic_instantiation declares an instance; it is equivalent to the instance
declaration (a package_declaration or subprogram_declaration) immediately
followed by the instance body, both at the place of the instantiation.

to:

A generic_instantiation declares an instance; it is equivalent to the instance
declaration (a package_declaration or subprogram_declaration) immediately
followed by the instance body, both at the place of the instantiation; except
that if the instance declaration is not a library unit declaration and is a
subprogram declaration that is a homograph of a prior subprogram_declaration in
the same declarative region, and the generic_instantiation is at a place where a
non-instance body would be a legal completion of the prior declaration, then the
generic_instantiation is equivalent to the instance body (only).

(The requirement that a non-instance body would be a legal completion prevents
things like this:)

    package Foo is
      procedure P;
       ...
      procedure P is new Some_Generic_Procedure;
    end Foo;

It might be useful to change 6.1(20) to clarify that the required completion
could be a body that is supplied by a generic instantiation.  I don't think
6.1(20) would *need* to be changed, though.

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

From: Tucker Taft
Sent: Wednesday, May 16, 2012  9:01 PM

This limitation was a conscious decision when we introduced renaming-as-body.
The problem is that if P is overloaded, it is entirely unclear from looking at
the instantiation that it is completing a particular specification.  For
example:

   procedure P(X : T1; Y : T2; Z : T3);

   procedure P(X : T2; Y : T1);

   procedure P(Z : T3);

   ...


   procedure P is new Gen(T1, T2, T3);  -- which "P" is this completing?

So we require that you instantiate, and then use a renaming-as-body to connect
it with an earlier spec.  The renaming-as-body repeats the parameter and result
profile, so it is much easier to make the connection.

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

From: Adam Beneschan
Sent: Wednesday, May 16, 2012  9:06 PM

Yeah, I kind of forgot that the parameters aren't present in the
generic_instantiation.  The poster's example didn't have any.

Oops.

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