Version 1.1 of ai05s/ai05-0200-1.txt
!standard 12.7(16) 10-02-12 AI05-0200-1/00
!class binding interpretation 10-02-12
!status work item 10-02-12
!status received 09-09-24
!priority Low
!difficulty Hard
!qualifier Omission
!subject Mismatches in formal package declarations
!summary
** TBD **
!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
** TBD **
!discussion
We want the generic in the question to be illegal. It serves no purpose to
postpone the error until it is instantiated.
It escapes the author as to how best accomplish this. Probably additional rules
need to be added after 12.7(4.1/2), but it's not clear what those ought to be.
--!corrigendum 3.9.3(4/2)
!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?
****************************************************************
Questions? Ask the ACAA Technical Agent