A static expression cannot have a generic formal type AI00190/06 1
890414 BI WJ
 !standard 04.09 (02) 890414 AI00190/06
!standard 04.03.02 (03)
!class binding interpretation 840313
!status approved by WG9/AJPO 860722
!status approved by Director, AJPO 860722
!status approved by WG9/Ada Board 860722
!status approved by Ada Board 860722
!status WG14/ADA Board approved 841127
!status WG14approved 841127
!status boardapproved 841126
!status committeeapproved 840628
!status workitem 840524
!status received 840313
!references 8300286, 8300376, 8300378, 8300379, 8300454
!topic A static expression cannot have a generic formal type
!summary 840903
A static expression is not allowed to have a generic formal type (including a
type derived from a generic formal type, directly or indirectly).
(Consequently, if an array's index subtype is a generic formal type,
aggregates for that dimension of the array can have only a single component
association and this component association must have a single choice.)
!question 840903
Consider this example:
generic
type T is range <>;
package PACK is
type ARR is array (T) of BOOLEAN;
X : ARR := (1_000_000 => FALSE,
1_000_001 => TRUE);  legal?
end PACK;
4.3.2(3) requires that when more than one component association is present in
an array aggregate, all the choices must be static. Consider the aggregate
(1_000_000 => FALSE, 1_000_001 => TRUE). This aggregate is illegal if 1_000_
001 does not belong to the index base type because evaluation of the literal
(i.e., its implicit conversion to the index base type) will raise an
exception [4.9(2)]. If the index base type is a generic formal type, it is
not known at compile time whether 1_000_001 belongs to the base type or not
(as long as 1_000_001 does not exceed SYSTEM.MAX_INT). If 1_000_001 belongs
to the base type for an instantiation, no exception will be raised. Does the
use of such an aggregate in a generic unit mean the legality of the unit's
instantiation depends on the range of the base type used in the
instantiation?
!recommendation 840903
A static expression is not allowed to have a generic formal type (including a
type derived from a generic formal type, directly or indirectly).
A static expression cannot have a generic formal type AI00190/06 2
890414 BI WJ
!discussion 840903
4.9 specifies the conditions under which an expression can be considered to
be static. If an expression has a formal generic type, it can only be static
if the formal type is an integer or real type and the primaries in the
expression are either numeric literals, named numbers, function calls as
specified in 4.9(7), or static expressions enclosed in parentheses. There
are no other possibilities. In particular, there are no enumeration literals
for a formal discrete type, and since 4.9(11) says a generic formal type is
not static, no constants satisfying 4.9(6) can be declared; moreover, there
are no static attributes for formal generic types, and a formal generic type
cannot be used in a static qualified expression.
In short, an expression such as 1 + 2 or 1.0 + 2.0 can apparently have a
generic formal type and still be considered static according to 4.9. Can
such expressions be used anywhere static expressions are required? An
examination of the Standard shows that rules requiring static expressions are
given in the following sections: 3.2.2(1), 3.5.4(3), 3.5.7(3), 3.5.9(3),
3.6.2(2), 3.7.3(3), 4.3.1(2), 4.3.2(3), 4.9(6, 11), 5.4(4), 9.8(1), 13.2(5,
12), and 13.3(4). These rules generally exclude static expressions that have
a generic formal type because:
1) A static expression is explicitly required to have a
universal type: 3.2.2(1), 3.6.2(2), 13.3(3,4);
2) The type of a static expression is explicitly required to be
INTEGER: 9.8(1);
3) An expression that must be static must have some integer or
real type that is determined independent of the context of
the expression. Since universal integer or universal real
is always acceptable in such contexts, expressions having
the form 1 + 2 or 1.0 + 2.0 can never be considered to have
a nonuniversal type [4.6(15], and so cannot have a generic
formal type: 3.5.4(3), 3.5.7(3), 3.5.9(3), 13.2(5, 12);
4) Expressions having a generic formal type are excluded
because a generic formal type is not static: 4.9(6, 11);
5) Generic formal types are explicitly excluded as the type of
a discriminant or as the expression in a case statement, and
so expressions having such types are not allowed as choices
in variant records, as discriminants of record aggregates,
or as choices in case statements: 3.7.3(3), 4.3.1(2),
5.4(4).
The only case remaining, choices in array aggregates [4.3.2(3)], has no
explicit or implicit exclusion regarding generic formal types. However,
since generic formal types are explicitly excluded by 3.7.3(3) and 5.4(4),
and since these are cases where allowing a generic formal type would mean the
legality of a generic instantiation would depend on the subtype used in its
instantiation, it is reasonable to conclude that the intent was to ensure the
legality of array aggregates would also be determined prior to instantiating
a generic unit.
A static expression cannot have a generic formal type AI00190/06 3
890414 BI WJ
The required legality check can be ensured in two ways: 1) by not allowing a
choice expression in an array aggregate to have a formal generic type; or 2)
by saying that any expression having a generic formal type is not static.
The latter rule would allow aggregates such as (1_000_000..1_000_001 =>
TRUE), since when there is a single choice, it is not required to be static
[4.3.2(3)]. If an array had an index type whose base type was a generic
formal type, the first alternative would forbid any choices for that
dimension except OTHERS, since OTHERS is not an expression. It would even
forbid T'FIRST..T'LAST, where T is the formal generic type.
Since the intent is to ensure instantiations containing aggregates are legal
if the generic template is legal, and since the second alternative is less
restrictive than the first and accomplishes the intent, the second
alternative is chosen as the recommended interpretation.
 !appendix 890318

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

 !section 04.09 (02) M. Woodger 890318 8301275
 !version 1983
 !topic Errors in AI00190/05

 !reference AI00190/05

 1. In the discussion section of this Commentary, the first paragraph
 describes the possibilities for an expression of generic formal
 type to be static, and excludes (for example) static qualified
 expressions.

 The second paragraph says "An examination of the Standard shows that
 rules requiring static expressions are given in the following
 sections: ... ". But the list given is not complete. For example,
 it omits 4.9(9) which concerns qualified expressions.

 This list is in fact only a list of the places that are RELEVANT to
 the set of possibilities described in the first paragraph.

 To correct this, replace "rules requiring" by
 "relevant rules requiring", in the second paragraph.

 2. At three places in the first paragraph, "formal generic type"
 should be replaced by the standard nomenclature (used everywhere else)
 which is "generic formal type".

 3. In the fifth paragraph of the discussion, item 3., the expression
 [4.6(15] should read [4.6(15)].
