!standard  12.7(4.1/2)                               11-03-17    AI05-0200-1/03
!class binding interpretation 10-02-12
!status Amendment 2012 11-03-24
!status ARG Approved  8-0-0  11-03-17
!status work item 10-02-12
!status received 09-09-24
!priority Low
!difficulty Hard
!qualifier Omission
!subject Mismatches in formal package declarations

!summary

Legality rules for formal packages with box associations are provided.
They are similar to legality rules for regular instantiations.

!question

Consider:

    generic
        type T is private;
        Init : T;
    package Pack1 is
        type Rec1 is record
            F1 : T := Init;
            F2 : T := Init;
        end record;
    end Pack1;

    with Pack1;
    generic
        type T2 is private;
        Val : Integer;
        with package The_Pack1 is new Pack1 (T2, Val); -- ??
    package Pack2 is
    end Pack2;

Most compilers give an error at the declaration of The_Pack1. But there doesn't
appear to be any rules that make such a declaration illegal. But an instance of
Pack2 could only be legal if the actual for T2 is Integer. So there doesn't seem
to be any reason to allow such cases.

One might depend on the equivalence between these actuals and the actuals in a
regular generic instantiation, and apply 12.4(4-5). But that doesn't work for
actuals designated by <>:

    generic
        type T3 is private;
        Val : T3;
        with package The_Pack1 is new Pack1 (T => <>, Init => Val);
    package Pack3 is
    end Pack3;

Here the type of Init isn't known in the generic.

Should rules be added here? (Yes.)

!recommendation

(See Summary.)

!wording

Add after 12.7 (4.1/2)

The rules for matching between formal_package_associations and the generic
formals of the template are as follows:

If all of the formal_package_associations are given by generic associations,
the generic_actual_parameters of the formal_package_associations shall be legal
for an instantiation of the template.

If a formal_package_association for a formal type T of the template is given by
<>, then the formal_package_association for any other generic_formal_parameter
of the template whose declaration mentions T directly or indirectly must be
given by <> as well.

AARM note:

The above rule is simple to state, though it does not reflect the fact that the
formal package functions like an instantiation of a special kind, where each
box association for a generic_formal_parameter F is replaced with a new entity
F' that has the same characteristics as F: if F is a formal discrete type then
F' is a discrete type, if F is a formal subprogram then F' is a subprogram
with a similar signature, etc. In practice this is achieved by making the
association into a copy of the declaration of the generic formal.

end AARM note.


!discussion

We want the generic in the question to be illegal. It serves no purpose to
postpone the error until it is instantiated.

!corrigendum 12.7(4.1/2)

@dinsa
A @fa<formal_package_actual_part> shall contain at most one
@fa<formal_package_association> for each formal parameter. If the
@fa<formal_package_actual_part> does not include "@b<others> => <>", each
formal parameter without an association shall have a @fa<default_expression>
or @fa<subprogram_default>.
@dinss
The rules for matching between @fa<formal_package_association>s and the generic
formals of the template are as follows:

@xbullet<If all of the @fa<formal_package_association>s are given by generic associations,
the @fa<generic_actual_parameter>s of the @fa<formal_package_association>s shall be legal
for an instantiation of the template.>

@xbullet<If a @fa<formal_package_association> for a formal type @i<T> of the template is given by
<@>, then the @fa<formal_package_association> for any other @fa<generic_formal_parameter>
of the template whose declaration mentions @i<T> directly or indirectly must be
given by <@> as well.>


!ACATS Test

An ACATS B-Test should be created that is similar to the example in the
question.

!appendix

!topic Mismatches in formal package declarations
!reference RM 12.7
!from Adam Beneschan 09-09-24
!discussion

GNAT gives an error on the declaration of The_Pack1:

    generic
        type T is private;
        Init : T;
    package Pack1 is
        type Rec1 is record
            F1 : T := Init;
            F2 : T := Init;
        end record;
    end Pack1;

    with Pack1;
    generic
        type T2 is private;
        Val : Integer;
        with package The_Pack1 is new Pack1 (T2, Val);
    package Pack2 is
    end Pack2;

It certainly seems like this should be an error.  But I can't find anything in
the Legality Rules in 12.7 that makes this an error.  As far as I can tell, no
instance of Pack2 can be legal unless the actual for T2 is Integer, and then it
will be legal if the actuals for Val and The_Pack1 follow the matching rules.
But it doesn't appear to me that this will be rejected until an attempt to
instantiate Pack2 takes place.

Is this the intent?

What about

    generic
        type T3 is private;
        Val : T3;
        with package The_Pack1 is new Pack1 (T => <>, Init => Val);
    package Pack3 is
    end Pack3;

It seems like this should be illegal also---if a formal package declaration uses
<> for a formal type ("T" in this case), I would think that <> should also be
required for any succeeding formal ("Init" in this case) whose declaration uses
that type.

Thoughts?

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

From: Adam Beneschan
Sent: Thursday, September 24, 2009  7:50 PM

> Is this the intent?

I may have answered the above question myself.  In a formal_package_declaration,
the items in the list are, syntactically, generic_associations --- same as in
12.3.  12.3(7) says that a generic_association defines a "generic actual
parameter", which can also be called simply an "actual"; then 12.4(4-5) might
apply.  The rules aren't really explicit, but it might be implied that the rules
about "actuals" in 12.4-12.7 apply as well to the "actuals" defined by
generic_associations in formal_package_declarations.

If that's good enough to solve the above problem, I'm still not sure that it can
be applied to the following case:

> What about
>
>     generic
>         type T3 is private;
>         Val : T3;
>         with package The_Pack1 is new Pack1 (T => <>, Init => Val);
>     package Pack3 is
>     end Pack3;

Supposing we used the same logic; now in the generic_association Init => Val,
the rules in 12.4 would say "The expected type for the actual [Val] is the type
of the formal".  But the type of the formal is <> --- i.e. there really isn't a
type.  So how would the rules apply in this case?

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

From: Edmond Schonberg
Sent: Thursday, October 21, 2010  1:34 PM

I've tried to make the amount of text commensurate with the importance of the issue.

[Following was version /01 of this AI.]

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

From: Bob Duff
Sent: Thursday, October 21, 2010  5:50 PM

Yeah, that seems wise.

Your wording seems good to me.

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

From: Edmond Schonberg
Sent: Friday, October 22, 2010  10:18 AM

Thanks for the check.  Intuitively the formal package functions like an instantiation
(and at the implementation level this is how it works)  but that is never stated
directly.  Therefore,  speaking about a legal set of actuals for a conceptual
instantiation seems like the simplest way to describe what is going on. I'm sure
this is just the zeroth approximation to the final wording!

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

From: Edmond Schonberg
Sent: Tuesday, March 15, 2011  1:35 PM

Here is an update of the proposed rules.  [This is version /02 - Editor.]
The relevant paragraph is as follows:

If all of the formal_package_associations are given by generic associations, the
set of generic_actual_parameters of the formal_package_associations shall be a
legal set of actuals for an instantiation of the template.

If a formal_package_association for a formal type T of the template is given by
<>, then the formal_package_association for any other generic_formal_parameter
of the template whose declaration mentions T directly or indirectly must be
given by a box as well.

AARM note:

The above rule is simple to state, though it does not reflect the fact that the
formal package functions like an instantiation of a special kind, where each box
association for a generic_formal_parameter F is replaced with a new entity F'
that has the same characteristics as F: if F is a formal discrete type then F'
is a discrete type, if F is a formal subprogram then F' is a subprogram with a
similar signature, etc. In practice this is achieved by making the association
into a copy of the declaration of the generic formal.

end AARM note.


The second paragraph is given as an easy-to-follow rule for the programmer (an
operational rule so to speak)  while the AARM note provides  an axiomatic rule
about the legality of some equivalent instantiation.

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

From: Bob Duff
Sent: Thursday, March 17, 2011  1:35 PM

Suggested wording for:

AI05-0200-1, Mismatches in formal package declarations

as discussed in today's phone meeting.  It currently says:

If all of the formal_package_associations are given by generic associations, the
set of generic_actual_parameters of the formal_package_associations shall be a
legal set of actuals for an instantiation of the template.

Change to:

If all of the formal_package_associations are given by generic associations, the
generic_actual_parameters of the formal_package_associations shall be legal for
an instantiation of the template.

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

From: Edmond Schonberg
Sent: Thursday, March 17, 2011  1:35 PM

Good. Shorter is better!

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