4.1.6 User-Defined Indexing

Aspect Description for Constant_Indexing: Defines function(s) to implement user-defined indexed_components.

Reason: We require these functions to return a reference type so that the object returned from the function can act like a variable. We need no similar rule for Constant_Indexing, since all functions return constant objects. 

Aspect Description for Variable_Indexing: Defines function(s) to implement user-defined indexed_components.

Reason: {AI22-0002-1} {AI22-0005-1} For a function that has a parameter of T or access T, a blanket rule in 13.1.1 requires the function to be a primitive operation of T, the wording about the same declaration list is redundant in that case. That 13.1.1 rule does not apply to functions that have parameters of T'Class or access T'Class (which is good, as those can never be primitive); the wording about the declaration list is necessary in that case. 

Ramification: Indexing can be provided for multiple index types by overloading routines with different parameter profiles. For instance, the map containers provide indexing on both cursors and keys by providing pairs of overloaded routines to the Constant_Indexing and Variable_Indexing aspects. 

Term entry: indexable container type — type that has user-defined behavior for indexing, via the Constant_Indexing or Variable_Indexing aspects

Reason: {AI12-0160-1} This (and the following Legality Rules) ensures that all descendants of an indexable container type have aspects with the same properties. This prevents generic contract problems with formal derived types.

{AI12-0104-1} {AI12-0138-1} A nonoverridable aspect allows the replacement of the implementation of an indexing function and the addition of a new indexing function for a derived type, but not the removal of an indexing function. This is necessary so that indexing can be used on objects of T'Class. So long as the tag of O is that of its nominal subtype, we do not want T'Class(O)(I) to mean something different than O(I). Thus we cannot allow a change in the function identified. As T'Class(O)(I) expands into a dispatching call, we need to ensure that there is a body for each such function -- but it is OK for that body to be changed from the original body (that's just normal dispatching). 

Ramification: A prefix can be an implicit_dereference (see 4.1), so an access-to-indexable_container_object can be the prefix (English meaning!) of a generalized_indexing.

Ramification: This means it is not interpreted as a constant indexing for the variable_name in the LHS of an assignment (not inside a primary), nor for the name used for an out or in out parameter (not allowed to be a constant), nor for the name in an object renaming (not inside a primary), unless there is no Variable_Indexing aspect defined. 

Ramification: In other words, the generalized_indexing is equivalent to:

{AI12-0005-1} where Indexing is the name specified for the Constant_Indexing or Variable_Indexing aspect. This equivalence is then resolved in the normal way; the aspect specifies a name, it does not denote declarations. 

{AI05-0139-2} Aspects Constant_Indexing and Variable_Indexing, and the generalized_indexing syntax are new. 

{AI12-0160-1} Correction: Prevented a derived type from specifying Constant_Indexing if the ancestor specified Variable_Indexing (and vice versa). This is necessary to preserve the intent that for an object Obj whose tag is that of its nominal subtype, T'Class(Obj)(I) always has the same meaning as Obj(I). Situations like this should be rare in practice; most types will either define both aspects or neither.

{AI12-0204-1} Correction: Added a rule that a generalized indexing is illegal if the equivalent prefixed view would be illegal. If the prefixed view would be illegal for any reason, Ada 2012 would have allowed the generalized indexing while Ada 2022 does not. This violated the principle that a generalized indexing and the equivalent prefixed view have the same semantics; practically, the code may not have worked anyway if a compiler implemented generalized indexing by code expansion into the canonical form. Thus, such code wasn't practically portable.

{AI12-0104-1} Corrigendum: Converted confusing and unnecessary normative wording about "overriding an aspect" into a note.

{AI12-0138-1} Corrigendum: Defined Constant_Indexing and Variable_Indexing to be nonoveridable. This is merely a new description for Legality Rules which already applied to these aspects.

{AI12-0428-1} Correction: Allowed the completion of a private type to use declarations from either the visible part or the private part.