8.6 The Context of Overload Resolution
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
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
The type resolution rules are intended to minimize
the need for implicit declarations and preference rules associated with
implicit conversion and dispatching operations.
Name Resolution Rules
resolution is applied separately to each complete context
counting inner complete contexts.] Each of the following constructs is
a complete context
We would make it the whole pragma
except that certain pragma arguments are allowed to be ambiguous, and
ambiguity applies to a complete context.
This means that the expression
is resolved without looking at the choices.
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
is plural here, because there are lots of trivial productions —
might also be all of the following, in this order: identifier
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
In most cases, a usage name denotes the view declared by the denoted
declaration. However, in certain cases, a usage name that denotes a declaration
and appears inside the declarative region of that same declaration, denotes
the current instance of the declaration. For example, within a 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.
Ramification: Unfortunately, we are not
confident that the above list is complete. We'll have to live with that.
To be honest: For “possible”
interpretations, the above information is tentative.
Discussion: A possible interpretation
(an input to overload resolution) contains information about what
a usage name might denote, but what it actually does denote
requires overload resolution to determine. Hence the term “tentative”
is needed for possible interpretations; otherwise, the definition would
A possible interpretation
is one that obeys the syntax rules and the visibility rules.
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
To be honest:
One rule that falls into
this category, but does not use the above-mentioned magic words, is the
rule about numbers of parameter associations in a call (see 6.4
Ramification: The Name Resolution Rules
are the ones that appear under the Name Resolution Rules heading. Some
Syntax Rules are written in English, instead of BNF. No rule is a Syntax
Rule or Name Resolution Rule unless it appears under the appropriate
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
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:
Ramification: As explained below, a pragma
argument is allowed to be ambiguous, so it can denote several declarations,
and all of the views declared by those declarations.
If a usage name appears within the declarative region
of a type_declaration
and 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_declaration
and 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 subtype_mark
of an access_definition
for an access-to-object type, or within the subtype of a parameter or
result of an access-to-subprogram type.
The phrase “within the 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. 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 with the value is the object associated (see 6.2)
with the evaluation execution of the usage name.
the purposes of Legality Rules, the current instance acts as a value
within an 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
To be honest:
The current instance of
a generic unit is the instance created by whichever generic_instantiation
is of interest at any given time.
A usage name that denotes a view also denotes the
entity of that view.
Ramification: Usually, a usage name denotes
only one declaration, and therefore one view and one entity.
The expected type
for a given expression
, or other
construct determines, according to the type resolution rules
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
Ramification: Expected types are defined
throughout the RM95. The most important definition is that, for a subprogram,
the expected type for the actual parameter is the type of the formal
The type resolution rules are trivial unless
either the actual or expected type is universal, class-wide, or of an
anonymous access type.
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
Ramification: This matching rule handles
(among other things) cases like the Val attribute, which denotes a function
that takes a parameter of type universal_integer.
The last part of the rule, “or to a universal
type that covers the class” implies that if the expected type for
an expression is universal_fixed, then an expression whose type
is universal_real (such as a real literal) is OK.
the expected type for a construct is a specific type T
, then the
type of the construct shall resolve either to T
rule is not
intended to create a preference for the specific type
— such a preference would cause Beaujolais effects.
to T'Class; or
to a universal type that covers
The case where the actual
'Class will only be legal as part of a call on a
dispatching operation; see 3.9.2
Operations of Tagged Types
”. Note that that rule is not a Name
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
In certain contexts, [such as
in a subprogram_renaming_declaration
the Name Resolution Rules define an expected profile
for a given
such cases, the name
shall resolve to the name of a callable entity whose profile is type
conformant with the expected profile.
The parameter and result sub
types are not used in overload resolution.
Only type conformance of profiles is considered during overload resolution.
Legality rules generally require at least mode conformance in addition,
but those rules are not used in overload resolution.
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_conversion
For example, the expected type for a string literal is required to be
a single string type. But the expected type for the operand of a type_conversion
is any type. Therefore, a string literal is not allowed as the operand
of a type_conversion
This is true even if there is only one string 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.
The first sentence is carefully worded so that it only mentions “expected
type” as part of identifying the interesting case, but doesn't
require that the context actually provide such an expected type. This
allows such constructs to be used inside of constructs that don't provide
an expected type (like qualified expressions and renames). Otherwise,
such constructs wouldn't allow aggregate
'Access, and so on.
Other than for the tested_simple_expression simple_expression
of a membership test, if the expected type for a name
is not the same as the actual type of the name
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
and the actual type is an anonymous access-to-object type
with designated type D2
, then D1
shall cover D2
and the name
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].
Reason: This rule prevents an implicit
conversion that would be illegal if it was an explicit conversion. For
instance, this prevents assigning an access-to-constant value into a
stand-alone anonymous access-to-variable object. It also covers convertibility
of the designated type and accessibility checks.
The rule also minimizes cases of implicit conversions
when the tag check or the accessibility check might fail. We word it
this way because access discriminants should also be disallowed if their
enclosing object is designated by an access parameter.
Ramification: This rule does not apply
to expressions that don't have expected types (such as the operand of
a qualified expression or the expression of a renames). We don't need
a rule like this in those cases, as the type needs to be the same; there
is no implicit conversion.
A complete context shall have at least one acceptable
interpretation; if there is exactly one, then that one is chosen.
Ramification: This, and the rule below
about ambiguity, are the ones that suck in all the Syntax Rules and Name
Resolution Rules as compile-time rules. Note that this and the ambiguity
rule have to be Legality Rules.
There is a preference
for the primitive operators (and range
of the root numeric types root_integer
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
, and the other is
not, the interpretation using the primitive operator (or range
of the root numeric type is preferred
reason for this preference is so that expressions involving literals
and named numbers can be unambiguous. For example, without the preference
rule, the following would be ambiguous:
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.
Reason: This preference is necessary
because of implicit conversion from an anonymous access type to a named
access type, which would allow the equality operator of any named access
type to be used to compare anonymous access values (and that way lies
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 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.
all of the declarations determined by its interpretations, and all of
the views declared by these declarations.
This applies to Inline, Suppress, Import, Export, and Convention pragma
For example, it is OK to say “pragma
=> 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
but those can't have overloading for other reasons. Note that almost
all of these pragmas are obsolescent (see J.10
), 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
which are given on individual declarations, are preferred in Ada 2012.
Note that if a pragma argument denotes a call
to a callable entity, rather than the entity itself, this exception does
not apply, and ambiguity is disallowed.
Note that we need to carefully define which
pragma-related rules are Name Resolution Rules, so that, for example,
does not pick up subprograms declared in enclosing declarative regions,
and therefore make itself illegal.
We say “statically denotes” in the
above rule in order to avoid having to worry about how many times the
in case it denotes more than one callable entity.
17 If a usage name has only one acceptable
interpretation, then it denotes the corresponding entity. However, this
does not mean that the usage name is necessarily legal since other requirements
exist which are not considered for overload resolution; for example,
the fact that an expression is static, whether an object is constant,
mode and subtype conformance rules, freezing rules, order of elaboration,
and so on.
Similarly, subtypes are not considered for overload
resolution (the violation of a constraint does not make a program illegal
but raises an exception during program execution).
Incompatibilities With Ada 83
new preference rule for operators of root numeric types is upward incompatible,
but only in cases that involved Beaujolais
effects in Ada 83.
Such cases are ambiguous in Ada 95.
Extensions to Ada 83
The rule that allows an
expected type to match an actual expression of a universal type, in combination
with the new preference rule for operators of root numeric types, subsumes
the Ada 83 "implicit conversion" rules for universal types.
Wording Changes from Ada 83
In Ada 83, it is not clear what the “syntax
rules” are. AI83-00157 states that a certain textual rule is a
syntax rule, but it's still not clear how one tells in general which
textual rules are syntax rules. We have solved the problem by stating
exactly which rules are syntax rules — the ones that appear under
the “Syntax” heading.
RM83 has a long list of the “forms”
of rules that are to be used in overload resolution (in addition to the
syntax rules). It is not clear exactly which rules fall under each form.
We have solved the problem by explicitly marking all rules that are used
in overload resolution. Thus, the list of kinds of rules is unnecessary.
It is replaced with some introductory (intentionally vague) text explaining
the basic idea of what sorts of rules are overloading rules.
It is not clear from RM83 what information is embodied in a “meaning”
or an “interpretation.” “Meaning” and “interpretation”
were intended to be synonymous; we now use the latter only in defining
the rules about overload resolution. “Meaning” is used only
informally. This subclause attempts to clarify what is meant by “interpretation.”
For example, RM83 does not make it clear that
overload resolution is required in order to match subprogram_bodies
with their corresponding declarations (and even to tell whether a given
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.
seem to imply that an interpretation embodies information about what
is denoted by each usage name, but not information about which syntactic
category each construct belongs to. However, it seems necessary to include
such information, since the Ada grammar is highly ambiguous. For example,
X(Y) might be a 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 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.)
Consider the declaration of Y (a complete context).
In the above example, overload resolution can easily determine the declaration,
and therefore the entity, denoted by Y, A, F, and I. However, given all
of that information, we still don't know whether F(I) is a function_call
or an indexed_component
is a function_call
(In the latter case, it is equivalent to F(7).all
It seems clear that the declaration of Y ought
to be considered ambiguous. We describe that by saying that there are
two interpretations, one as a 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.
It is the intent that the
Ada 95 preference rule for root numeric operators is more locally enforceable
than that of RM83-4.6(15). It should also eliminate interpretation shifts
due to the addition or removal of a use_clause
(the so called Beaujolais
Cases like the Val attribute are now handled
using the normal type resolution rules, instead of having special cases
that explicitly allow things like “any integer type.”
Incompatibilities With Ada 95
Ada 95 allowed name resolution to distinguish between
anonymous access-to-variable and access-to-constant types. This is similar
to distinguishing between subprograms with in
and in out
parameters, which is known to be bad. Thus, that part of the rule was
dropped as we now have anonymous access-to-constant types, making this
much more likely.
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.
If there is any code like this (such code should
be rare), it will be ambiguous in Ada 2005.
Extensions to Ada 95
Generalized the anonymous access resolution rules
to support the new capabilities of anonymous access types (that is, access-to-subprogram
We now allow the creation of self-referencing types via anonymous access
types. This is an extension in unusual cases involving task and protected
types. For example:
task type T;
task body T is
procedure P (X : access T) is -- Illegal in Ada 95, legal in Ada 2005
Wording Changes from Ada 95
Corrected the “single expected type” so that it works in
contexts that don't have expected types (like object renames and qualified
expressions). This fixes a hole in Ada 95 that appears to prohibit using
'Access, character literals, string literals, and allocator
in qualified expressions.
Incompatibilities With Ada 2005
Implicit conversion is now allowed from anonymous
access-to-object types to general access-to-object types. Such conversions
can make calls ambiguous. That can only happen when there are two visible
subprograms with the same name and have profiles that differ only by
a parameter that is of a named or anonymous access type, and the actual
argument is of an anonymous access type. This should be rare, as many
possible calls would be ambiguous even in Ada 2005 (including allocator
and any actual of a named access type if the designated types are the
Extensions to Ada 2005
Implicit conversion is allowed from anonymous access-to-object
types to general access-to-object types if the designated type is convertible
and runtime checks are minimized. See also the incompatibilities section.
Wording Changes from Ada 2005
Added a requirement here that implicit conversions are convertible to
the appropriate type. This rule was scattered about the Standard, we
moved a single generalized version here.
Inconsistencies With Ada 2012
Corrigendum: Added a
rule to specify that the current instance of a type or subtype is a value
within an 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
Wording Changes from Ada 2012
Corrigendum: Added wording to clarify that
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_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.
Ada 2005 and 2012 Editions sponsored in part by Ada-Europe