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.
The expected type for an array_aggregate
(that is not a subaggregate) shall be a single array type. The
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.
An others choice
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:
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 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.
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).
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.
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.
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;
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.
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).
Correction: Fixed so the check for components
outside of the array applies to both expressions
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
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.
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