4.3.3 Array Aggregates
Language Design Principles
Subaggregates do not have
a type. They correspond to part of an array. For example, with a matrix,
a subaggregate would correspond to a single row of the matrix. The definition
of "n-dimensional" array_aggregate
applies to subaggregates as well as aggregate
that have a type.
Name Resolution Rules
The expected type for an array_aggregate
(that is not a subaggregate) shall be a single array type.
component type of this array type is the expected type for each array
component expression of the array_aggregate
We already require a single array or record type or record extension
for an aggregate
The above rule requiring a single array type (and similar ones for record
and extension aggregates) resolves which kind of aggregate you have.
In an m-dimensional array_aggregate
[(including a subaggregate)], where m >= 2, each of the expression
has to be an (m–1)-dimensional subaggregate.
is allowed for an array_aggregate
only if an applicable index constraint
applies to the array_aggregate
[An applicable index constraint is a constraint provided
by certain contexts where an array_aggregate
is permitted that can be used to determine the bounds of the array value
specified by the aggregate.] Each of the following contexts (and none
other) defines an applicable index constraint:
For an explicit_actual_parameter
of a return statement, the return expression of
an expression function,
the initialization expression in an object_declaration
or a default_expression
[(for a parameter or a component)], when the nominal subtype of the corresponding
formal parameter, generic formal parameter, function return object, expression
function return object,
object, or component is a constrained
array subtype, the applicable index constraint is the constraint of the
Reason: This case is broken out because
the constraint comes from the actual subtype of the variable (which is
always constrained) rather than its nominal subtype (which might be unconstrained).
For the operand of a qualified_expression
denotes a constrained array subtype, the applicable index constraint
is the constraint of the subtype;
For a component expression
in an aggregate
if the component's nominal subtype is a constrained array subtype, the
applicable index constraint is the constraint of the subtype;
Here, the array_aggregate
is being used within a larger aggregate.
RM83 omitted this case, presumably
as an oversight. We want to minimize situations where an expression
becomes illegal if parenthesized.
Reason: This avoids generic contract
model problems, because only mode conformance is required when matching
actual subprograms with generic formal subprograms.
Discussion: We now allow a nonstatic
others choice even if there are other array component expressions
Ramification: This implies that each
component must be specified exactly once. See AI83-309.
This has to apply even if there is only one static discrete_choice
a single choice has to represent a contiguous range (a subtype_mark
with a static predicate might represent a discontiguous set of values).
If the (single) choice is a dynamic subtype, we don't need to make this
check as no predicates are allowed (see 3.2.4
and thus the range has to be contiguous.
The subtype (and nominal subtype) of an index parameter
is the corresponding index subtype.
evaluation of an array_aggregate
of a given array type proceeds in two steps:
of this aggregate and of its subaggregates are evaluated in an arbitrary
order, and converted to the corresponding index type;
The array component expressions of the aggregate are evaluated in an
arbitrary order and their values are converted to the component subtype
of the array type; an array component expression is evaluated once for
each associated component.
Ramification: Subaggregates are not separately
evaluated. The conversion of the value of the component expressions to
the component subtype might raise Constraint_Error.
We don't need to say that <> is evaluated once for each component,
as <> means that each component is initialized by default
That means that the actions defined for default initialization are applied
to each component individually. Initializing one component by default
and copying that to the others would be an incorrect implementation in
general (although it might be OK if the default initialization is known
to be constant).
together with the preceding rule that “The array component expressions
of the aggregate are evaluated in an arbitrary order”, this implies
that an index parameter can take on its values in an arbitrary order.
This is different than, for example, a loop parameter.
bounds of the index range of an array_aggregate
[(including a subaggregate)] are determined as follows:
For an array_aggregate
with an others
choice, the bounds are those of the corresponding
index range from the applicable index constraint;
For a positional_array_aggregate
[(or equivalent string_literal
without an others
choice, the lower bound is that of the corresponding
index range in the applicable index constraint, if defined, or that of
the corresponding index subtype, if not; in either case, the upper bound
is determined from the lower bound and the number of expression
[(or the length of the string_literal
We don't need to say that each
index value has to be covered exactly once, since that is a ramification
of the general rule on aggregate
that each component's value has to be specified exactly once.
For an array_aggregate
a check is made that the index range defined by its bounds is compatible
with the corresponding index subtype.
Discussion: In RM83, this was phrased
more explicitly, but once we define "compatibility" between
a range and a subtype, it seems to make sense to take advantage of that
Ramification: The definition of compatibility
handles the special case of a null range, which is always compatible
with a subtype. See AI83-00313.
For an array_aggregate
with an others
choice, a check is made that no expression
or <> is specified for an index value outside the bounds determined
by the applicable index constraint.
Discussion: RM83 omitted this case, apparently
through an oversight. AI83-00309 defines this as a dynamic check, even
though other Ada 83 rules ensured that this check could be performed
statically. We now allow an others choice to be dynamic, even
if it is not the only choice, so this check now needs to be dynamic,
in some cases. Also, within a generic unit, this would be a nonstatic
check in some cases.
For a multidimensional
a check is made that all subaggregates that correspond to the same index
have the same bounds.
Ramification: No array bounds “sliding”
is performed on subaggregates.
Reason: If sliding were performed, it
would not be obvious which subaggregate would determine the bounds of
the corresponding index.
The exception Constraint_Error
is raised if any of the above checks fail.
Examples of array
aggregates with positional associations:
(7, 9, 5, 1, 3, 2, 4, 8, 6, 0)
Table'(5, 8, 4, 1, others
=> 0) -- see 3.6
Examples of array
aggregates with named associations:
(1 .. 5 => (1 .. 8 => 0.0)) -- two-dimensional
(1 .. N => new Cell) -- N new cells, in particular for N = 0
Table'(2 | 4 | 10 => 1, others
Schedule'(Mon .. Fri => True, others
=> False) -- see 3.6
Schedule'(Wed | Sun => False, others
Vector'(1 => 2.5) -- single-component vector
Examples of two-dimensional
-- Three aggregates for the same value of subtype Matrix(1..2,1..3) (see 3.6):
((1.1, 1.2, 1.3), (2.1, 2.2, 2.3))
(1 => (1.1, 1.2, 1.3), 2 => (2.1, 2.2, 2.3))
(1 => (1 => 1.1, 2 => 1.2, 3 => 1.3), 2 => (1 => 2.1, 2 => 2.2, 3 => 2.3))
Examples of aggregates
as initial values:
A : Table := (7, 9, 5, 1, 3, 2, 4, 8, 6, 0); -- A(1)=7, A(10)=0
B : Table := (2 | 4 | 10 => 1, others => 0); -- B(1)=0, B(10)=1
C : constant Matrix := (1 .. 5 => (1 .. 8 => 0.0)); -- C'Last(1)=5, C'Last(2)=8
D : Bit_Vector(M .. N) := (M .. N => True); -- see 3.6
E : Bit_Vector(M .. N) := (others
F : String(1 .. 1) := (1 => 'F'); -- a one component aggregate: same as "F"
G : constant Matrix :=
(for I in 1 .. 4 =>
(for J in 1 .. 4 =>
(if I=J then 1.0 else 0.0))); -- Identity matrix
Example of an array aggregate with defaulted others choice and with
an applicable index constraint provided by an enclosing record aggregate:
Buffer'(Size => 50, Pos => 1, Value => String'
=> <>)) -- see 3.7
Incompatibilities With Ada 83
Ada 95, no applicable index constraint is defined for a parameter in
a call to a generic formal subprogram; thus, some aggregates that are
legal in Ada 83 are illegal in Ada 95. For example:
subtype S3 is String (1 .. 3);
with function F (The_S3 : in S3) return Integer;
package Gp is
I : constant Integer := F ((1 => '!', others => '?'));
-- The aggregate is legal in Ada 83, illegal in Ada 95.
This change eliminates generic contract model
Extensions to Ada 83
We now allow "named
with others" aggregates in all contexts where there is an applicable
index constraint, effectively eliminating what was RM83-4.3.2(6). Sliding
never occurs on an aggregate with others, because its bounds come from
the applicable index constraint, and therefore already match the bounds
of the target.
The legality of an others choice is no
longer affected by the staticness of the applicable index constraint.
This substantially simplifies several rules, while being slightly more
flexible for the user. It obviates the rulings of AI83-00244 and AI83-00310,
while taking advantage of the dynamic nature of the "extra values"
check required by AI83-00309.
Named array aggregates are permitted even if
the index type is descended from a formal scalar type. See 4.9
Wording Changes from Ada 83
We now separate named and positional array aggregate
syntax, since, unlike other aggregates, named and positional associations
cannot be mixed in array aggregates (except that an others choice
is allowed in a positional array aggregate).
We have also reorganized the presentation to
handle multidimensional and one-dimensional aggregates more uniformly,
and to incorporate the rulings of AI83-00019, AI83-00309, etc.
Extensions to Ada 95
Wording Changes from Ada 95
Inconsistencies With Ada 2005
Fixed so the check for components
outside of the array applies to both expression
and <>s. As <> was a new feature in Ada 2005, there should
be little existing code that depends on a <> component that is
specified outside of the array (and that is nonsense anyway, that a compiler
is likely to detect even without an explicit language rule disallowing
Wording Changes from Ada 2005
Inconsistencies With Ada 2012
Corrigendum: Fixed so
that the Default_Component_Value (if any) is used to initialize components
specified with <>. This is what users would expect, and all Ada
2012 implementation known at the time of this writing initialize with
the Default_Component_Value, so it is unlikely that anyone will be affected
by this inconsistency.
Extensions to Ada 2012
Wording Changes from Ada 2012
Corrigendum: Added expression functions
to the contexts that provide an applicable index constraint, because
expression functions are handled separately in static semantics and legality
Ada 2005 and 2012 Editions sponsored in part by Ada-Europe