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 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.
Name Resolution Rules
Overload
resolution is applied separately to each
complete context, not
counting inner complete contexts. Each of the following constructs is
a
complete context:
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
for each usage name, which declaration it denotes
(and, therefore, which view and which entity it denotes); and
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 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.
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 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.
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
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.
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
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.
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 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.
NOTE 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).
Ada 2005 and 2012 Editions sponsored in part by Ada-Europe
