8.6 The Context of Overload Resolution
This Reference Manual output has not been verified, and may contain omissions or errors. Report any problems on the tracking issue
[ Because declarations can be overloaded, it is possible for an occurrence of a usage name to have more than one possible interpretation; in most cases, ambiguity is disallowed. This subclause describes how the possible interpretations resolve to the actual interpretation.
Certain rules of the language (the Name Resolution Rules) are considered “overloading rules”. If a possible interpretation violates an overloading rule, it is assumed not to be the intended interpretation; some other possible interpretation is assumed to be the actual interpretation. On the other hand, violations of nonoverloading rules do not affect which interpretation is chosen; instead, they cause the construct to be illegal. To be legal, there usually has to be exactly one acceptable interpretation of a construct that is a “complete context”, not counting any nested complete contexts.
The syntax rules of the language and the visibility rules given in 8.3 determine the possible interpretations. Most type checking rules (rules that require a particular type, or a particular class of types, for example) are overloading rules. Various rules for the matching of formal and actual parameters are overloading rules.]
Language Design Principles
Name Resolution Rules4
[Overload resolution is applied separately to each complete context, not counting inner complete contexts.] Each of the following constructs is a complete context:
loop_parameter_specificationis a declaration, and hence a complete context.
pragma, except that certain pragma arguments are allowed to be ambiguous, and ambiguity applies to a complete context.
- The selecting_
expressionis resolved without looking at the choices.
- The variable_
assignment_statementA, if the
expressionof A contains one or more
An (overall) interpretation of a complete context embodies its meaning, and includes the following information about the constituents of the complete context, not including constituents of inner complete contexts:
- for each constituent of the complete context, to which syntactic categories it belongs, and by which syntax rules; and
expressionmight also be all of the following, in this order:
relation. Basically, we're trying to capture all the information in the parse tree here, without using compiler-writer's jargon like “parse tree”.
- for each usage name, which declaration it denotes (and, therefore, which view and which entity it denotes); and
task_bodyother than in an
access_definition, a usage name that denotes the
task_type_declarationdenotes the object containing the currently executing task, and not the task type declared by the declaration.
- for a complete context that is a
declarative_item, whether or not it is a completion of a declaration, and (if so) which declaration it completes.
A possible interpretation is one that obeys the syntax rules and the visibility rules. An acceptable interpretation is a possible interpretation that obeys the overloading rules[, that is, those rules that specify an expected type or expected profile, or specify how a construct shall resolve or be interpreted.]
The interpretation of a constituent of a complete context is determined from the overall interpretation of the complete context as a whole. [Thus, for example, “interpreted as a
function_call”, means that the construct's interpretation says that it belongs to the syntactic category
[Each occurrence of] a usage name denotes the declaration determined by its interpretation. It also denotes the view declared by its denoted declaration, except in the following cases:
- If a usage name appears within the declarative region of a
type_declarationand denotes that same
type_declaration, then it denotes the current instance of the type (rather than the type itself); the current instance of a type is the object or value of the type that is associated with the execution that evaluates the usage name. Similarly, if a usage name appears within the declarative region of a
subtype_declarationand denotes that same
subtype_declaration, then it denotes the current instance of the subtype. These rules do not apply if the usage name appears within the
access_definitionfor an access-to-object type, or within the subtype of a parameter or result of an access-to-subprogram type.
type_declaration. Also, within a
protected_body, we need to be able to denote the current task or protected object. (For a
single_protected_declaration, the rule about current instances is not needed.) We exclude anonymous access types so that they can be used to create self-referencing types in the natural manner (otherwise such types would be illegal).
subtype_mark” in the “this rule does not apply” part is intended to cover a case like access T'Class appearing within the declarative region of T: here T denotes the type, not the current instance.
- Within an
aspect_specificationfor a type or subtype, the current instance represents a value of the type; it is not an object. Unless otherwise specified, the nominal subtype of this value is given by the subtype itself (the first subtype in the case of a
type_declaration), prior to applying any predicate specified directly on the type or subtype. If the type or subtype is by-reference, the associated object of the value is the object associated (see 6.2) with the evaluation of the usage name.
aspect_specification. It might really be an object (and has to be for a by-reference type), but that isn't discoverable by direct use of the name of the current instance.
- If a usage name appears within the declarative region of a
generic_declaration(but not within its
generic_formal_part) and it denotes that same
generic_declaration, then it denotes the current instance of the generic unit (rather than the generic unit itself). See also 12.3.
generic_instantiationis of interest at any given time.
namethat denotes the
generic_declarationdenotes the generic unit, which implies that it is not overloadable.
A usage name that denotes a view also denotes the entity of that view.
The expected type for a given
name, or other construct determines, according to the type resolution rules given below, the types considered for the construct during overload resolution. [ The type resolution rules provide support for class-wide programming, universal literals, dispatching operations, and anonymous access types:]
- If a construct is expected to be of any type in a class of types, or of the universal or class-wide type for a class, then the type of the construct shall resolve to a type in that class or to a universal type that covers the class.
- If the expected type for a construct is a specific type T, then the type of the construct shall resolve either to T, or:
- to T'Class; or
- to a universal type that covers T; or
- when T is a specific anonymous access-to-object type (see 3.10) with designated type D, to an access-to-object type whose designated type is D'Class or is covered by D; or
- when T is a named general access-to-object type (see 3.10) with designated type D, to an anonymous access-to-object type whose designated type covers or is covered by D; or
- when T is an anonymous access-to-subprogram type (see 3.10), to an access-to-subprogram type whose designated profile is type conformant with that of T.
In certain contexts, [such as in a
subprogram_renaming_declaration,] the Name Resolution Rules define an expected profile for a given
name; in such cases, the
name shall resolve to the name of a callable entity whose profile is type conformant with the expected profile.
When a construct is one that requires that its expected type be a single type in a given class, the type of the construct shall be determinable solely from the context in which the construct appears, excluding the construct itself, but using the requirement that it be in the given class. Furthermore, the context shall not be one that expects any type in some class that contains types of the given class; in particular, the construct shall not be the operand of a
type_conversionis any type. Therefore, a character literal is not allowed as the operand of a
type_conversion. This is true even if there is only one character type in scope (which is never the case). The reason for these rules is so that the compiler will not have to search “everywhere” to see if there is exactly one type in a class in scope.
aggregates, 'Access, and so on.
Other than for the tested_
simple_expression of a membership test, if the expected type for a
expression is not the same as the actual type of the
expression, the actual type shall be convertible to the expected type (see 4.6); further, if the expected type is a named access-to-object type with designated type D1 and the actual type is an anonymous access-to-object type with designated type D2, then D1 shall cover D2, and the
expression shall denote a view with an accessibility level for which the statically deeper relationship applies[; in particular it shall not denote an access parameter nor a stand-alone access object].
A complete context shall have at least one acceptable interpretation; if there is exactly one, then that one is chosen.
There is a preference for the primitive operators (and
ranges) of the root numeric types root_integer and root_real. In particular, if two acceptable interpretations of a constituent of a complete context differ only in that one is for a primitive operator (or
range) of the type root_integer or root_real, and the other is not, the interpretation using the primitive operator (or
range) of the root numeric type is preferred.
N : constant := 123;
if N > 100 then -- Preference for root_integer ">" operator.
Similarly, there is a preference for the equality operators of the universal_access type (see 4.5.2). If two acceptable interpretations of a constituent of a complete context differ only in that one is for an equality operator of the universal_access type, and the other is not, the interpretation using the equality operator of the universal_access type is preferred.
For a complete context, if there is exactly one overall acceptable interpretation where each constituent's interpretation is the same as or preferred (in the above sense) over those in all other overall acceptable interpretations, then that one overall acceptable interpretation is chosen. Otherwise, the complete context is ambiguous.
A complete context other than a
pragma_argument_association shall not be ambiguous.
A complete context that is a
pragma_argument_association is allowed to be ambiguous (unless otherwise specified for the particular pragma), but only if every acceptable interpretation of the pragma argument is as a
name that statically denotes a callable entity. Such a
name denotes all of the declarations determined by its interpretations, and all of the views declared by these declarations.
pragmas. For example, it is OK to say “pragma Export(C, Entity_Name => P.Q);”, even if there are two directly visible P's, and there are two Q's declared in the visible part of each P. In this case, P.Q denotes four different declarations. This rule also applies to certain pragmas defined in the Specialized Needs Annexes. It almost applies to Pure, Elaborate_Body, and Elaborate_All
pragmas, but those can't have overloading for other reasons. Note that almost all of these pragmas are obsolescent (see J.10 and J.15), and a major reason is that this rule has proven to be too broad in practice (it is common to want to specify something on a single subprogram of an overloaded set, that can't be done easily with this rule).
Aspect_specifications, which are given on individual declarations, are preferred in Ada 2012.
pragmaInline does not pick up subprograms declared in enclosing declarative regions, and therefore make itself illegal.
nameis evaluated, in case it denotes more than one callable entity.
Incompatibilities With Ada 83
Extensions to Ada 83
Wording Changes from Ada 83
subprogram_bodieswith their corresponding declarations (and even to tell whether a given
subprogram_bodyis the completion of a previous declaration). Clearly, the information needed to do this is part of the “interpretation” of a
subprogram_body. The resolution of such things is defined in terms of the “expected profile” concept. Ada 95 has some new cases where expected profiles are needed — the resolution of P'Access, where P might denote a subprogram, is an example.
indexed_component, and no context-free/syntactic information can tell the difference. It seems like we should view X(Y) as being, for example, “interpreted as a
function_call” (if that's what overload resolution decides it is). Note that there are examples where the denotation of each usage name does not imply the syntactic category. However, even if that were not true, it seems that intuitively, the interpretation includes that information. Here's an example:
type A is access T;
type T is array(Integer range 1..10) of A;
I : Integer := 3;
function F(X : Integer := 7) return A;
Y : A := F(I); -- Ambiguous? (We hope so.)
function_call. (In the latter case, it is equivalent to F(7).all(I).)
function_call, and one as an
indexed_component. These interpretations are both acceptable to the overloading rules. Therefore, the complete context is ambiguous, and therefore illegal.
use_clause(the so called Beaujolais effect).
declarative_items that are not declarations or
context_items. We have added these, and also replaced the “must be determinable” wording of RM83-5.4(3) with the notion that the expression of a
case_statementis a complete context.
Incompatibilities With Ada 95
type Cacc is access constant Integer;
procedure Proc (Acc : access Integer) ...
procedure Proc (Acc : Cacc) ...
List : Cacc := ...;
Proc (List); -- OK in Ada 95, ambiguous in Ada 2005.
Extensions to Ada 95
task type T; 34.t/2task body T is procedure P (X : access T) is -- Illegal in Ada 95, legal in Ada 2005 ... end P; begin ... end T;
Wording Changes from Ada 95
aggregates, 'Access, character literals, string literals, and
allocators in qualified expressions.
Incompatibilities With Ada 2005
allocators and any actual of a named access type if the designated types are the same).
Extensions to Ada 2005
Wording Changes from Ada 2005
Inconsistencies With Ada 2012
aspect_specification. This could be inconsistent if a predicate or invariant uses the Constrained attribute on the current instance (it will always be False now, while it might have returned True in original Ada 2012). More likely, a usage of a current instance as a prefix of an attribute will become illegal (such as Size or Alignment). Any such code is very tricky. Moreover, as this is a new feature of Ada 2012, there are not that many predicates and invariants, and the ones that exist are very unlikely to be this tricky. Thus we do not believe that there will be any practical effect to this change, other than to explicitly allow common implementation strategies.
Wording Changes from Ada 2012
case_expressionis a complete context, just like that of a
case_statement. Clearly, everyone expects these to work the same way. Moreover, since it would be a lot of extra work to treat
case_expressions differently, it is quite unlikely that any compiler would implement the much more complicated resolution necessary (and we are not aware of any that did). Therefore, we didn't document this as a potential incompatibility.