4.3.3 Array Aggregates
Language Design Principles
Syntax
Ramification: 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
aggregates
that have a type.
Name Resolution Rules
{
AI95-00287-01}
{expected type (array_aggregate)
[partial]} The expected type for an
array_aggregate
(that is not a subaggregate) shall be a single array type.
{expected
type (array_aggregate component expression) [partial]} The
component type of this array type is the expected type for each array
component expression of the
array_aggregate.
Ramification: {
AI95-00287-01}
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.
{expected type (array_aggregate
discrete_choice) [partial]} The expected
type for each
discrete_choice
in any
discrete_choice_list
of a
named_array_aggregate
is the type of the
corresponding index;
{corresponding
index (for an array_aggregate)} the corresponding
index for an
array_aggregate
that is not a subaggregate is the first index of its type; for an (n–m)-dimensional
subaggregate within an
array_aggregate
of an n-dimensional type, the corresponding index is the index in position
m+1.
Legality Rules
Ramification: In an m-dimensional
array_aggregate
[(including a subaggregate)], where m >= 2, each of the
expressions
has to be an (m–1)-dimensional subaggregate.
An
others choice
is allowed for an
array_aggregate
only if an
applicable index constraint applies to the
array_aggregate.
{applicable index constraint}
[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:
{
AI95-00318-02}
For an
explicit_actual_parameter,
an
explicit_generic_actual_parameter,
the
expression
of a return statement, 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, object,
or component is a constrained array subtype, the applicable index constraint
is the constraint of the subtype;
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
whose
subtype_mark
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;
Discussion: Here, the
array_aggregate
with
others is being used within a larger aggregate.
For a parenthesized
expression,
the applicable index constraint is that, if any, defined for the
expression.
Discussion: 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
as well.
Ramification: This implies that each
component must be specified exactly once. See AI83-309.
Static Semantics
Dynamic Semantics
{evaluation
(array_aggregate) [partial]} The evaluation
of an
array_aggregate
of a given array type proceeds in two steps:
1.
Any
discrete_choices
of this aggregate and of its subaggregates are evaluated in an arbitrary
order, and converted to the corresponding index type;
{implicit
subtype conversion (choices of aggregate) [partial]}
2.
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.
{implicit
subtype conversion (expressions of aggregate) [partial]}
Ramification: Subaggregates are not separately
evaluated. The conversion of the value of the component expressions to
the component subtype might raise Constraint_Error.
{bounds
(of the index range of an array_aggregate)} The
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
expressions
[(or the length of the
string_literal)];
Reason: 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
aggregates
that each component's value has to be specified exactly once.
{Range_Check
[partial]} {check,
language-defined (Range_Check)} 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
definition.
Ramification: The definition of compatibility
handles the special case of a null range, which is always compatible
with a subtype. See AI83-00313.
{Index_Check
[partial]} {check,
language-defined (Index_Check)} For an
array_aggregate
with an
others choice, a check is made that no
expression
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.
{Index_Check
[partial]} {check,
language-defined (Index_Check)} For a
multidimensional
array_aggregate,
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.
{Constraint_Error
(raised by failure of run-time check)} The
exception Constraint_Error is raised if any of the above checks fail.
Examples
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 => 0)
Schedule'(Mon .. Fri => True,
others => False) --
see 3.6
Schedule'(Wed | Sun => False,
others => True)
Vector'(1 => 2.5) --
single-component vector
Examples of two-dimensional
array aggregates:
--
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 => True);
F : String(1 .. 1) := (1 => 'F'); --
a one component aggregate: same as "F"
{
AI95-00433-01}
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'('x',
others => <>)) --
see 3.7
Incompatibilities With Ada 83
{
incompatibilities
with Ada 83}
In 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);
...
generic
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.
end Gp;
This change eliminates generic contract model
problems.
Extensions to Ada 83
{
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
and AI83-00190.
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