4.3.1 Record Aggregates
In a
record_aggregate,
a value is specified for each component of the record or record extension
value, using either a named or a positional association.
Syntax
Name Resolution Rules
The expected type for a
record_aggregate
shall be a single record type or record extension.
For a positional association, the component (including
possibly a discriminant) in the corresponding relative position (in the
declarative region of the type), counting only the needed components;
For a named association with one or more
component_selector_names,
the named component(s);
For a named association with the reserved word
others, all needed components that are not associated with some
previous association.
Legality Rules
If the type of a
record_aggregate
is a record extension, then it shall be a descendant of a record type,
through one or more record extensions (and no private extensions).
If a
record_component_association
with an
expression
has two or more associated components, all of them shall be of the same
type, or all of them shall be of anonymous access types whose subtypes
statically match. In addition, Legality Rules are enforced separately
for each associated component.
For a
record_aggregate
or
extension_aggregate,
if a
variant_part
P is nested within a
variant
V that is not selected by the discriminant value governing the
variant_part
enclosing
V, then there is no restriction on the discriminant
governing
P. Otherwise, the value of the discriminant that governs
P shall be given by a static expression, or by a nonstatic expression
having a constrained static nominal subtype. In this latter case of a
nonstatic expression, there shall be exactly one
discrete_choice_list
of
P that covers each value that belongs to the nominal subtype
and satisfies the predicates of the subtype, and there shall be at least
one such value.
use the box compound delimiter <> rather
than an
expression;
Dynamic Semantics
For the evaluation of a
record_component_association_list,
any per-object constraints (see
3.8) for components
specified in the association list are elaborated and any
expressions
are evaluated and converted to the subtype of the associated component.
Any constraint elaborations and
expression
evaluations (and conversions) occur in an arbitrary order, except that
the
expression
for a discriminant is evaluated (and converted) prior to the elaboration
of any per-object constraint that depends on it, which in turn occurs
prior to the evaluation and conversion of the
expression
for the component with the per-object constraint.
If the value of a discriminant that governs a selected
variant_part
is given by a nonstatic
expression,
and the evaluation of that
expression
yields a value that does not belong to the nominal subtype of the
expression,
then Constraint_Error is raised.
Examples
Example of a record
aggregate with positional associations:
(4, July, 1776) --
see 3.8 Examples of record
aggregates with named associations:
(Day => 4, Month => July, Year => 1776)
(Month => July, Day => 4, Year => 1776)
(Disk, Closed, Track => 5, Cylinder => 12) --
see 3.8.1
(Unit => Disk, Status => Closed, Cylinder => 9, Track => 1)
Examples of component
associations with several choices:
(Value => 0, Succ|Pred =>
new Cell'(0,
null,
null)) --
see 3.10.1 -- The allocator is evaluated twice:
-- Succ and Pred designate different cells
(Value => 0, Succ|Pred => <>) --
see 3.10.1 -- Succ and Pred will be set to null
Examples of record
aggregates for tagged types (see 3.9 and 3.9.1):
Expression'(null record)
Literal'(Value => 0.0)
Painted_Point'(0.0, Pi/2.0, Paint => Red)
Ada 2005 and 2012 Editions sponsored in part by Ada-Europe
