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 Rules
4[Overload resolution is applied separately to each complete context, not counting inner complete contexts.] Each of the following constructs is a complete context:
- A
context_item
. 6 - A
declarative_item
or declaration.
loop_parameter_specification
is 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_
expression
of acase_statement
orcase_expression
.
expression
is resolved without looking at the choices. - The variable_
name
of anassignment_statement
A, if theexpression
of A contains one or moretarget_name
s.
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
expression
might also be all of the following, in this order: identifier
, name
, primary
, factor
, term
, simple_expression
, and 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_body
other than in an access_definition
, a usage name that denotes the task_type_declaration
denotes 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 function_call
.]
[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_declaration
and denotes that sametype_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 asubtype_declaration
and denotes that samesubtype_declaration
, then it denotes the current instance of the subtype. These rules do not apply if the usage name appears within thesubtype_mark
of anaccess_definition
for 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 task_body
or protected_body
, we need to be able to denote the current task or protected object. (For a single_task_declaration
or 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_specification
for 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 atype_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 itsgeneric_formal_part
) and it denotes that samegeneric_declaration
, then it denotes the current instance of the generic unit (rather than the generic unit itself). See also 12.3.
generic_instantiation
is of interest at any given time. generic_formal_part
, a name
that denotes the generic_declaration
denotes 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 expression
, 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.
Legality Rules
27/2When 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_conversion
.
type_conversion
is 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. aggregate
s, 'Access, and so on. Other than for the tested_simple_expression
of a membership test, if the expected type for a name
or expression
is not the same as the actual type of the name
or 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 name
or 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 range
s) 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.
...
end if;
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.
pragma
s. 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 pragma
s, 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_specification
s, which are given on individual declarations, are preferred in Ada 2012.pragma
Inline does not pick up subprograms declared in enclosing declarative regions, and therefore make itself illegal.name
is evaluated, in case it denotes more than one callable entity. Incompatibilities With Ada 83
Extensions to Ada 83
Wording Changes from Ada 83
subprogram_bodies
with their corresponding declarations (and even to tell whether a given subprogram_body
is 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.function_call
or an 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 T;
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
or an indexed_component
whose prefix
is a 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).pragma_argument_association
s, declarative_item
s that are not declarations or aspect_clause
s, and context_item
s. 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_statement
is 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
aggregate
s, 'Access, character literals, string literals, and allocator
s in qualified expressions. Incompatibilities With Ada 2005
allocator
s 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
expression
of a case_expression
is 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_expression
s 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.