AI22-0146-1

!standard 4.1.6(2/5)                                    26-04-30  AI22-0146-1/04

!standard 4.1.6(3/5)

!standard 4.3.5(9/6)

!class Binding Interpretation 25-12-05

!status Revision-202Y  25-12-16

!status ARG Approved  8-0-2  25-12-11

!status work item 25-12-05

!status received 25-12-05

!assigned author Randy Brukardt

!submitter Gary Dismukes/Tucker Taft

!priority Medium

!difficulty Medium

!qualifier Clarification

!subject Expected profile of subprogram-valued aspects

!summary

When the profile of a subprogram-valued aspect is only partially defined, we clearly define what is expected for resolution purposes. We also clarify that the modes of expected profiles never participate in resolution.

!issue

AI22-0084-1 confirms that the only Name Resolution Rule for most subprogram-valued aspects is given in 13.1.1(8/6):

• an aspect that denotes a subprogram, the aspect_definition shall be a name; the expected profile for the name is the profile required for the aspect of the associated entity; additionally, unless otherwise specified, only subprograms declared within the declarative region of the entity associated with the aspect are considered;

For most aspects, the “profile required by the aspect” is given by a specification or by wording that completely defines the expected profile. But some profiles (for instance, for Constant_Indexing) only partially define the needed profile. It is not clear whether the intent is to define a new kind of resolution, or whether some other resolution is intended.

Additionally, the container aggregate definition has a set of Name Resolution Rules, but those rules include modes not normally included in resolution.

!recommendation

Clearly state the profile for the Constant_Indexing and Variable_Indexing aspects. Clarify that the modes do not participate in resolution of the subprograms associated with the Aggregate aspect.

!wording

Modify 4.1.6(2/5):

This aspect shall be specified by a name that denotes one or more functions declared immediately within the same declaration list in which T, or the declaration completed by T, is declared. {The expected profile of this aspect is any function.} All such functions shall have at least two parameters, the first of which is of type T or T'Class, or is an access-to-constant parameter with designated type T or T'Class.

Modify 4.1.6(3/5):

This aspect shall be specified by a name that denotes one or more functions declared immediately within the same declaration list in which T, or the declaration completed by T, is declared. {The expected profile of this aspect is any function.} All such functions shall have at least two parameters, the first of which is of type T or T'Class, or is an access parameter with designated type T or T'Class. All such functions shall have a return type that is a reference type (see 4.1.5), whose reference discriminant is of an access-to-variable type.

Add after 4.3.5(9/6):

Overload resolution for these expected profiles occurs as described in 8.6; in particular the modes of the expected profiles do not participate in the overload resolution but rather are checked afterwards as a Legality Rule.

[Author’s note: We could also just make this a To-Be-Honest note in the AARM. I worry that these rules being different from those for other aspects (in terms of actually being under a Name Resolution Rules heading) might cause some implementers to think that they are actually different in the way that they are resolved. The best approach would be to remove the modes from these descriptions and add a Legality Rule about them instead, but that is a lot more changes.]

Add after AARM 8.6(26.a/3):

AARM Discussion: Note that the expected profile might not be completely defined. Some parameters may be allowed to be of any type in a category (such as any discrete type, or even any type), similarly to the expected type of a construct. Some profiles might even allow an unlimited number of additional parameters. In such cases, the defined parameters and the type information available for those parameters are used for resolution.

!discussion

A future AI will address certain issues identified with these rules, particularly relating to generic formal parts, and to partial profiles associated with indexing and the potentially defaulted parameters of a Default_Iterator.

The conclusion of AI22-0084-1 follows directly from the basic design principles of the Ada Reference Manual. In particular, a rule is only a Name Resolution Rule if it falls under that heading, or if it has an explicit statement to that effect. The only other rules that apply to overloading resolution are (A) syntax rules, and (B) definitions of terms used by Name Resolution Rules (such as “view” and “expected profile”).

For the specific case of subprogram-valued aspects, the only explicitly designated Name Resolution Rule is 13.1.1(8/6):

• an aspect that denotes a subprogram, the aspect_definition shall be a name; the expected profile for the name is the profile required for the aspect of the associated entity; additionally, unless otherwise specified, only subprograms declared within the declarative region of the entity associated with the aspect are considered;

The intent of 13.1.1(8/6) was to follow the existing model of resolution for subprogram-valued attributes. Indeed, this wording is almost exactly the same as that of 13.3(4):

For an attribute_definition_clause that specifies an attribute that denotes a subprogram, the expected profile for the name is the profile required for the attribute.

There are two reasons for this. First, we wanted the resolution of aspects and attributes to work the same in cases where either can be used (as in the stream-oriented attributes). It would be confusing if one could get different answers depending on how an aspect/attribute is specified. Second, we didn’t want compilers to have to implement some new kind of resolution, and we didn’t want programmers to have to think about such a resolution.

It should be noted that 8.6(26) says that “expected profile” resolution only requires type conformance. Modes, aliasing, “not null”, and the like are not considered for resolution purposes. Any requirements for those things in the profile of an aspect are enforced as Legality Rules after resolution. We intend for that to occur here as well.

This analysis makes it clear that the rules for most aspects are sufficient as written. Only the type profile as defined for each aspect is used for overload resolution; everything else is enforced later as Legality Rules. Let’s look at a couple of special cases.

For Constant_Indexing, there are two sentences that talk about what is expected for the aspect. These were written as separate sentences as the intent is that the first sentence is the profile for resolution purposes, and the remainder is used only as a following legality check. However, given the way that the profile is defined for other aspects, it would be easy to confuse the secondary characteristics as part of the profile. Thus, we explicitly state the intended expected profile. Variable_Indexing is handled the same way for the same reasons.

[Aside: Reviewers are often confused as to why these two aspects are handled differently than all of the others. The indexing aspects match an unlimited number of (overloaded) functions, and the limits on the profiles of those functions are very weak. (For instance, the one of the proposed universal string types has four defined constant indexings.) All other aspects match a defined number (usually one) of fully defined profiles, and only allow a defined number of matches (again, usually one). With fully defined profiles, it makes sense to use name resolution to pick up the specific routine desired; there will be little confusion if there also exist routines with non-matching profiles.

For the indexing aspects, however, the only definition for which indexings are allowed are the profiles of the overloaded set of functions. The presence of non-matching overloaded functions could easily lead a reader into thinking that indexing is supported for some profile for which it really is not supported. Moreover, a mistake in a profile would be hidden: it could only be detected when a client tries to use an index profile that is misdefined (which could be far away, both in a code and temporal sense). These sets of routines really need to be disjoint from anything else declared in the same declarative region, simply so that readers can easily see what is supported and what is not for indexing.

As such, we use a very liberal overloading resolution rule, only for the indexing aspects, and reject anything that does not belong to the indexing set. Note that the names of functions used in an indexing set are irrelevant (almost all calls will use the indexing, which does not include that name); if any of those routines need publicly facing versions, those probably should be renames of the ones used to define indexing so that they are not constrained by the requirements of defining indexing.

The resolution of the parts of the Aggregate aspect are defined by a bunch of rules under the Name Resolution Rules heading. However, these rules include modes of the parameters. These are not traditionally included in resolution, and it would require extra work from implementers to include those. As such, we add a sentence to clarify that the modes given do not participate in resolution.

!corrigendum 4.1.6(2/5)

@drepl

@xhang{@xterm{Constant_Indexing}This aspect shall be specified by a @fa{name} that denotes one or more functions declared immediately within the same declaration list in which @i{T}, or the declaration completed by @i{T}, is declared. All such functions shall have at least two parameters, the first of which is of type @i{T} or @i{T}'Class, or is an access-to-constant parameter with designated type @i{T} or @i{T}'Class.}

@dby

@xhang{@xterm{Constant_Indexing}This aspect shall be specified by a @fa{name} that denotes one or more functions declared immediately within the same declaration list in which @i{T}, or the declaration completed by @i{T}, is declared. The expected profile of this aspect is any function. All such functions shall have at least two parameters, the first of which is of type @i{T} or @i{T}'Class, or is an access-to-constant parameter with designated type @i{T} or @i{T}'Class.}

!corrigendum 4.1.6(3/3)

@drepl

@xhang{@xterm{Variable_Indexing}This aspect shall be specified by a @fa{name} that denotes one or more functions declared immediately within the same declaration list in which @i{T}, or the  declaration completed by @i{T}, is declared. All such functions shall have at least two parameters, the first of which is of type @i{T} or @i{T}'Class, or is an access parameter with designated type @i{T} or @i{T}'Class. All such functions shall have a return type that is a reference type (see @ref{4.1.5}), whose reference discriminant is of an access-to-variable type.}

@dby

@xhang{@xterm{Variable_Indexing}This aspect shall be specified by a @fa{name} that denotes one or more functions declared immediately within the same declaration list in which @i{T}, or the  declaration completed by @i{T}, is declared. The expected profile of this aspect is any function. All such functions shall have at least two parameters, the first of which is of type @i{T} or @i{T}'Class, or is an access parameter with designated type @i{T} or @i{T}'Class. All such functions shall have a return type that is a reference type (see @ref{4.1.5}), whose reference discriminant is of an access-to-variable type.}

!corrigendum 4.3.5(9/6)

@dinsa

The @i{procedure_}@fa{name} specified for Add_Named or Assign_Indexed for an Aggregate aspect shall denote exactly one procedure that has three parameters, the first an @b{in out} parameter of the container type, the second an @b{in} parameter whose type is called the @i{key type} of the container type, and the third, an @b{in} parameter whose type is called the @i{element type} of the container type.

@dinst

Overload resolution for these expected profiles occurs as described in @ref{8.6}; in particular the modes of the expected profiles do not participate in the overload resolution but rather are checked afterwards as a Legality Rule.

!ACATS test

Existing ACATS B-Tests should be checked that they treat the profile as an overloading rule, and the rest of the rules as Legality Rules.

!appendix

From: Randy Brukardt

Sent: Tuesday, December 16, 2025

Subsequent discussions around this AI show that there still is some confusion (including by me!) about what the RM says about the “expected profile” of an aspect. Let me summarize what is known about the topic.

• “Expected profile” is used in a number of existing rules other than aspects: subprogram renaming, prefix of the Access attribute, actual subprogram matching for generic formal subprograms, and most similarly to aspects, attribute definition clauses. (It probably should be used for the resolution of the reducer_name in a reduction attribute; there doesn’t appear to be a clear description of how that subprogram is resolved, the wording seems to imply that subtypes are somehow involved.) It would be odd to use a different term for aspect resolution.
• The closely related term “expected type” does not necessarily identify a single type; it could identify a category of types like “any discrete type”, “any task type”, or even “any type”. An expected profile is essentially a set of expected types, so it would be surprising if those types could not identify a category rather than an individual type. Nothing in 8.6 (where resolution is defined) implies otherwise.
• Similarly, nothing in 8.6 implies that an expected profile needs to define all of the parameters involved. It seems logical that a profile could only weakly specify the number of parameters needed (such as “2 or more parameters”). A parameter not specified can be thought of as similar to a parameter with an expected type of “any type”.
• We have been assuming that weakly specified profiles are OK since Ada 2012. In particular, aspect Default_Iterator requires 2 parameters and allows arbitrary other parameters so long as those parameters have defaults. At a minimum, the Dewar rule applies here (we meant what we said, even if it implies that weakly specified profiles exist).
• Defining the resolution of all subprogram names in the same way is preferable as it makes future enhancements to Ada easier. Future capabilities would not have to worry about the different ways that subprograms are resolved. For instance, a hypothetical conditional subprogram name would be much easier to define if all subprogram names were resolved by expected profiles. (The fact that not all resolution had expected types has caused definitional problems for things like conditional expressions; the problem was bad enough that we eventually redefined qualified expressions to provide an expected type. It would be a bad idea to cause a similar problem with resolution of subprogram names.)

Based on these reasons, I’ve added the following AARM note to clarify that “expected profiles” may not be complete as part of my Editorial Review of the AI.

This note is intended to clarify the current state of the rules, and should not be taken as the last word on this subject. Future AIs might further clarify this model.