- 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 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 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
- 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
- A declarative_item or declaration.
- A pragma_argument_association.
- The expression of a case_statement.
- 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.
- 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.
- 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 numeric 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 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 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 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 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.
- 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
- 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).
-- Email comments, additions, corrections, gripes, kudos, etc. to:
Magnus Kempe -- Magnus.Kempe@di.epfl.ch
Page last generated: 95-03-12