4.3.5 Container Aggregates

Term entry: container aggregate — construct used to define a value of a type that represents a collection of elements, by explicitly specifying the elements in the collection

Aspect Description for Aggregate: Mechanism to define user-defined aggregates.

Ramification: {AI22-0020-1} As this aspect is described with syntax, it has to be given exactly as specified here. That means it cannot be given as a positional aggregate, nor can the order of the elements be changed. For instance, New_Indexed always has to occur before Assign_Indexed, and Empty always has to be first. 

Reason: The parameter of In the function case, the parameter, if present, may be used to specify an initial size for the container, in anticipation of adding elements to it. For a positional aggregate, or a named aggregate that doesn't use an iterator, it will be initialized with the number of elements. For a named aggregate that uses an iterator, the implementation is permitted to estimate the number of elements that the iterator will produce, but it is not required to do so. 

Reason: The New_Indexed function is used instead of Empty as the first step of creating an aggregate that is initialized using the Assign_Indexed procedure. 

Reason: Both access parameters and explicitly aliased parameters add additional requirements on the corresponding actual parameter. These complicate the description and implementation of container aggregates with little benefit. Thus we make them illegal. This means neither the element type nor the key type (if any) of the container type can be an anonymous access type.

Ramification: Since the Aggregate aspect is nonoverridable, this rule is rechecked on any derived type that inherits an Aggregate aspect. 

Ramification: The first Legality Rule has to be rechecked in instances, if a type with an Aggregate aspect is derived from a formal private type, in case the actual type for the private type is an array type. The last Legality Rule has to be rechecked in instances, in case an actual type for an abstract formal type is not abstract. 

Reason: {AI12-0212-1} Unlike other aggregates, container aggregates have to be surrounded with brackets rather than parentheses. Using brackets allows writing zero- and one-element positional aggregates. (Were we to use parentheses, a one-element positional aggregate would look the same as and would always be interpreted as a parenthesized expression.) Unlike the case for arrays, where it is always possible to give bounds to work around this gap, such an aggregate could not be written at all for a sequence type (such as a list) where there is no index or key to use. 

Reason: Only an element of an indexed aggregate can be left uninitialized, because the compiler can simply omit producing an Assign_Indexed operation for the given index. For other kinds of aggregates, there are no operations that add an element without giving it a value. We could have defined such (optional) operations, but they would have added significant complication to an already complex feature without adding much additional expressive power. Note that, to be consistent with array aggregates, we do not support specifying <> in an iterated_element_association.

Ramification: If there is a key_expression in an iterated_element_association, it determines the key of each added key/value pair, rather than the loop parameter. But if there is no key_expression, the loop parameter itself is used as the key. 

Reason: The above is trying to mimic the rules for named_array_aggregates, without others. 

Implementation Note: This value ought to be an estimate for the number of elements in the aggregate, if one is available. If not, it is suggested to use the default value for the parameter if one exists, and zero otherwise. 

Implementation defined: The value of the parameter to Empty for some container_aggregates.

Ramification: In this case, the value of the loop parameter is not directly relevant, though presumably it appears within the expression of the iterated_element_association.

{AI12-0212-1} Container aggregates are new. 

{AI22-0031-1} Corrigendum: Expressions in a named_container_aggregate are evaluated once for each key value. This is consistent with other kinds of aggregate. Original Ada 2022 evaluated the expressions once per association. If a program depends on the number of times the expressions are evaluated, the behavior could change. This sort of program is unusual, and most depend on each component having a separate evaluation, so this change is more likely to fix a bug than cause one. 

{AI22-0002-1} Corrigendum: Unlike original Ada 2022, Empty can only be given by a function, not by a constant, as a constant does not make sense when the associated type is derived. As a new Ada 2022 feature, the specification of container aggregates should be rare, and the fix is easy: just replace the constant by an expression function returning the constant.

{AI22-0021-1} Corrigendum:Adjusted the rules about resolution of subprograms to avoid depending upon properties like limitedness of the parameter types (we do not do this elsewhere in the language). Also, some rules were added to make some unusual cases illegal that could have caused the aggregate implementation to be illegal. In both of these cases, unusual programs that were legal in original Ada 2022 are illegal in Ada 202y. As this is a new Ada 2022 feature, and the situations involved are unlikely, it is not expected that this will affect any existing code.

{AI22-0032-1} Corrigendum:The subprograms specified for an Aggregate aspect cannot be abstract unless the associated type is abstract; abstract subprograms were allowed in original Ada 2022. It is highly unlikely that any code using abstract subprograms in an Aggregate aspect exists, as such subprograms have no body but will be called when an aggregate is used for the type (usually causing internal errors in compilers).  

{AI22-0018-1} Corrigendum:A named_container_aggregate with a key_choice with a discrete_range no longer has to be an indexed aggregate. There was no reason for this restriction. 

{AI22-0031-1} Corrigendum: Added wording to clarify that calls defined in this subclause are evaluated as calls are defined in 6.4. While this could cause a program to raise an exception where it previously did not, this is just specifying otherwise unspecified behavior and does so as as Ada programmer would expect.

{AI22-0031-1} Corrigendum: Increased flexibility by removing an order requirement on the calls to Add_Indexed. This does not require any change to an existing implementation or program.