Contents Index Search Previous Next
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 clause describes how the possible interpretations resolve to the
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 non-overloading 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.
Name Resolution Rules
resolution is applied separately to each complete context
counting inner complete contexts. Each of the following constructs is
a complete context
- A declarative_item
- A pragma_argument_association.
- The expression
of a case_statement.
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
- for each usage name, which declaration
it denotes (and, therefore, which view and which entity it denotes);
- 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.
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
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
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
- 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.
A usage name that denotes a view also denotes
the entity of that view.
for a given expression
, or other construct determines,
according to the type resolution rules
given below, the types
considered for the construct during overload resolution.
type resolution rules provide support for class-wide programming, universal
numeric literals, dispatching operations, and anonymous access types:
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 expected type for a construct is a specific type T, then the
type of the construct shall resolve either to T, or:
- to a universal type that
covers T; or
- when T is an anonymous
access type (see 3.10) with designated type
D, to an access-to-variable type whose designated type is D'Class
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
cases, the name
shall resolve to
the name of a callable entity whose profile is type conformant with the
When the expected type for
a construct is required to be a single
type in a given class,
the type expected for 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; the type of
the construct is then this single expected type. 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
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
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
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.
16 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).
Contents Index Search Previous Next Legal