Unformatted version of **ai05s/ai05-0200-1.txt version 1.6**

Other versions for file**ai05s/ai05-0200-1.txt**

Other versions for file

!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

!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:

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 <>:

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

Should rules be added here? (Yes.)

!recommendation

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

Insert after the paragraph:

A formal_package_actual_part shall contain at most one
formal_package_association for each formal parameter. If the
formal_package_actual_part does not include "**others** => <>", each
formal parameter without an association shall have a default_expression
or subprogram_default.

the new paragraphs:

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.

!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! ****************************************************************

Questions? Ask the ACAA Technical Agent