Go to the first, previous, next, last section, table of contents.

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 See section 8.3 Visibility, 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:
    1. A context_item.
    2. declarative_item or declaration.
    3. A statement.
    4. A pragma_argument_association.
    5. The expression of a case_statement.

  1. 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:
    1. for each constituent of the complete context, to which syntactic categories it belongs, and by which syntax rules; and
    2. for each usage name, which declaration it denotes (and, therefore, which view and which entity it denotes); and
    3. 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.

  1. 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.
  2. 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.
  3. 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:
    1. 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.
    2. 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 See section 12.3 Generic Instantiation.

  1. A usage name that denotes a view also denotes the entity of that view.
  2. 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:
    1. 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.
    2. If the expected type for a construct is a specific type T, then the type of the construct shall resolve either to T, or:
      1. to T'Class; or
      2. to a universal type that covers T; or
      3. when T is an anonymous access type, See section 3.10 Access Types, with designated type D, to an access-to-variable type whose designated type is D'Class or is covered by D.

  1. 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

  2. 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.
  3. A complete context shall have at least one acceptable interpretation; if there is exactly one, then that one is chosen.
  4. 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.
  5. 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.
  6. A complete context other than a pragma_argument_association shall not be ambiguous.
  7. 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. @NOTES
  8. (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.
  9. 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).

Go to the first, previous, next, last section, table of contents.