Prev | Up | ____ | Back | Forward
TOC -- / --.-- / --.--.-- | Index | Search | Syntax | Help


8.6 The Context of Overload Resolution

(1)
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.
(2)
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.
(3)
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
(4)
Overload resolution is applied separately to each complete context, not counting inner complete contexts. Each of the following constructs is a complete context:
(5)
(6)
(7)
(8)
(9)
(10)
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:
(11)
(12)
(13)
(14)
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.
(15)
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.
(16)
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:
(17)
(18)
(19)
A usage name that denotes a view also denotes the entity of that view.
(20)
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:
(21)
(22)
(23)
(24)
(25)
(26)
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)
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.
(28)
A complete context shall have at least one acceptable interpretation; if there is exactly one, then that one is chosen.
(29)
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.
(30)
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.
(31)
A complete context other than a pragma_argument_association shall not be ambiguous.
(32)
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.

(33)
(34)


Prev | Up | ____ | Back | Forward
TOC -- / --.-- / --.--.-- | Index | Search | Syntax | Help

Ada WWW Home -- Email comments, additions, corrections, gripes, kudos, etc. to:

Magnus Kempe -- Magnus.Kempe@di.epfl.ch
Copyright statement
Page last generated: 95-03-12