8.6 The Context of Overload Resolution

The type resolution rules are intended to minimize the need for implicit declarations and preference rules associated with implicit conversion and dispatching operations. 

Ramification: A loop_parameter_specification is a declaration, and hence a complete context. 

Reason: We would make it the whole pragma, except that certain pragma arguments are allowed to be ambiguous, and ambiguity applies to a complete context. 

Ramification: This means that the expression is resolved without looking at the choices. 

Ramification: Syntactic categories is plural here, because there are lots of trivial productions — an expression might also be all of the following, in this order: identifier, name, primary, factor, term, simple_expression, and relation. Basically, we're trying to capture all the information in the parse tree here, without using compiler-writer's jargon like “parse tree”.

Ramification: {AI95-00382-01} In most cases, a usage name denotes the view declared by the denoted declaration. However, in certain cases, a usage name that denotes a declaration and appears inside the declarative region of that same declaration, denotes the current instance of the declaration. For example, within a task_body other than in an access_definition, a usage name that denotes the task_type_declaration denotes the object containing the currently executing task, and not the task type declared by the declaration. 

Ramification: Unfortunately, we are not confident that the above list is complete. We'll have to live with that.

To be honest: For “possible” interpretations, the above information is tentative. 

Discussion: A possible interpretation (an input to overload resolution) contains information about what a usage name might denote, but what it actually does denote requires overload resolution to determine. Hence the term “tentative” is needed for possible interpretations; otherwise, the definition would be circular. 

To be honest: One rule that falls into this category, but does not use the above-mentioned magic words, is the rule about numbers of parameter associations in a call (see 6.4).

Ramification: The Name Resolution Rules are the ones that appear under the Name Resolution Rules heading. Some Syntax Rules are written in English, instead of BNF. No rule is a Syntax Rule or Name Resolution Rule unless it appears under the appropriate heading. 

Ramification: As explained below, a pragma argument is allowed to be ambiguous, so it can denote several declarations, and all of the views declared by those declarations. 

Reason: {AI95-00382-01} This is needed, for example, for references to the Access attribute from within the type_declaration. Also, within a task_body or protected_body, we need to be able to denote the current task or protected object. (For a single_task_declaration or single_protected_declaration, the rule about current instances is not needed.) We exclude anonymous access types so that they can be used to create self-referencing types in the natural manner (otherwise such types would be illegal). 

Discussion: {AI95-00382-01} The phrase “within the subtype_mark” in the “this rule does not apply” part is intended to cover a case like access T'Class appearing within the declarative region of T: here T denotes the type, not the current instance. 

Ramification: For the purposes of Legality Rules, the current instance acts as a value within an aspect_specification. It might really be an object (and has to be for a by-reference type), but that isn't discoverable by direct use of the name of the current instance. 

To be honest: The current instance of a generic unit is the instance created by whichever generic_instantiation is of interest at any given time. 

Ramification: Within a generic_formal_part, a name that denotes the generic_declaration denotes the generic unit, which implies that it is not overloadable.

Ramification: Usually, a usage name denotes only one declaration, and therefore one view and one entity. 

Ramification: Expected types are defined throughout the RM95. The most important definition is that, for a subprogram, the expected type for the actual parameter is the type of the formal parameter.

The type resolution rules are trivial unless either the actual or expected type is universal, class-wide, or of an anonymous access type. 

Ramification: This matching rule handles (among other things) cases like the Val attribute, which denotes a function that takes a parameter of type universal_integer.

The last part of the rule, “or to a universal type that covers the class” implies that if the expected type for an expression is universal_fixed, then an expression whose type is universal_real (such as a real literal) is OK. 

Ramification: This rule is not intended to create a preference for the specific type — such a preference would cause Beaujolais effects. 

Ramification: This will only be legal as part of a call on a dispatching operation; see 3.9.2, “Dispatching Operations of Tagged Types”. Note that that rule is not a Name Resolution Rule. 

This paragraph was deleted.{AI95-00409-01}

Ramification: The case where the actual is access-to-D'Class will only be legal as part of a call on a dispatching operation; see 3.9.2, “Dispatching Operations of Tagged Types”. Note that that rule is not a Name Resolution Rule. 

Ramification: {AI05-0239-1} The parameter and result subtypes are not used in overload resolution. Only type conformance of profiles is considered during overload resolution. Legality rules generally require at least mode conformance in addition, but those rules are not used in overload resolution. 

Ramification: {AI95-00230-01} {AI12-0005-1} For example, the expected type for a character literal is required to be a single character type. But the expected type for the operand of a type_conversion is any type. Therefore, a character literal is not allowed as the operand of a type_conversion. This is true even if there is only one character type in scope (which is never the case). The reason for these rules is so that the compiler will not have to search “everywhere” to see if there is exactly one type in a class in scope. 

Discussion: {AI95-00332-01} The first sentence is carefully worded so that it only mentions “expected type” as part of identifying the interesting case, but doesn't require that the context actually provide such an expected type. This allows such constructs to be used inside of constructs that don't provide an expected type (like qualified expressions and renames). Otherwise, such constructs wouldn't allow aggregates, 'Access, and so on. 

Reason: This rule prevents an implicit conversion that would be illegal if it was an explicit conversion. For instance, this prevents assigning an access-to-constant value into a stand-alone anonymous access-to-variable object. It also covers convertibility of the designated type and accessibility checks.

The rule also minimizes cases of implicit conversions when the tag check or the accessibility check might fail. We word it this way because access discriminants should also be disallowed if their enclosing object is designated by an access parameter. 

Ramification: This rule does not apply to expressions that don't have expected types (such as the operand of a qualified expression or the expression of a renames). We don't need a rule like this in those cases, as the type needs to be the same; there is no implicit conversion. 

Ramification: This, and the rule below about ambiguity, are the ones that suck in all the Syntax Rules and Name Resolution Rules as compile-time rules. Note that this and the ambiguity rule have to be Legality Rules. 

Reason: The reason for this preference is so that expressions involving literals and named numbers can be unambiguous. For example, without the preference rule, the following would be ambiguous: 

Reason: This preference is necessary because of implicit conversion from an anonymous access type to a named access type, which would allow the equality operator of any named access type to be used to compare anonymous access values (and that way lies madness). 

Ramification: {AI95-00224-01} {AI05-0229-1} This applies to Inline, Suppress, Import, Export, and Convention pragmas. For example, it is OK to say “pragma Export(C, Entity_Name => P.Q);”, even if there are two directly visible P's, and there are two Q's declared in the visible part of each P. In this case, P.Q denotes four different declarations. This rule also applies to certain pragmas defined in the Specialized Needs Annexes. It almost applies to Pure, Elaborate_Body, and Elaborate_All pragmas, but those can't have overloading for other reasons. Note that almost all of these pragmas are obsolescent (see J.10 and J.15), and a major reason is that this rule has proven to be too broad in practice (it is common to want to specify something on a single subprogram of an overloaded set, that can't be done easily with this rule). Aspect_specifications, which are given on individual declarations, are preferred in Ada 2012.

Note that if a pragma argument denotes a call to a callable entity, rather than the entity itself, this exception does not apply, and ambiguity is disallowed.

Note that we need to carefully define which pragma-related rules are Name Resolution Rules, so that, for example, a pragma Inline does not pick up subprograms declared in enclosing declarative regions, and therefore make itself illegal.

We say “statically denotes” in the above rule in order to avoid having to worry about how many times the name is evaluated, in case it denotes more than one callable entity. 

The new preference rule for operators of root numeric types is upward incompatible, but only in cases that involved Beaujolais effects in Ada 83. Such cases are ambiguous in Ada 95. 

The rule that allows an expected type to match an actual expression of a universal type, in combination with the new preference rule for operators of root numeric types, subsumes the Ada 83 "implicit conversion" rules for universal types.

In Ada 83, it is not clear what the “syntax rules” are. AI83-00157 states that a certain textual rule is a syntax rule, but it's still not clear how one tells in general which textual rules are syntax rules. We have solved the problem by stating exactly which rules are syntax rules — the ones that appear under the “Syntax” heading.

RM83 has a long list of the “forms” of rules that are to be used in overload resolution (in addition to the syntax rules). It is not clear exactly which rules fall under each form. We have solved the problem by explicitly marking all rules that are used in overload resolution. Thus, the list of kinds of rules is unnecessary. It is replaced with some introductory (intentionally vague) text explaining the basic idea of what sorts of rules are overloading rules.

{AI05-0299-1} It is not clear from RM83 what information is embodied in a “meaning” or an “interpretation”. “Meaning” and “interpretation” were intended to be synonymous; we now use the latter only in defining the rules about overload resolution. “Meaning” is used only informally. This subclause attempts to clarify what is meant by “interpretation”.

For example, RM83 does not make it clear that overload resolution is required in order to match subprogram_bodies with their corresponding declarations (and even to tell whether a given subprogram_body is the completion of a previous declaration). Clearly, the information needed to do this is part of the “interpretation” of a subprogram_body. The resolution of such things is defined in terms of the “expected profile” concept. Ada 95 has some new cases where expected profiles are needed — the resolution of P'Access, where P might denote a subprogram, is an example.

RM83-8.7(2) might seem to imply that an interpretation embodies information about what is denoted by each usage name, but not information about which syntactic category each construct belongs to. However, it seems necessary to include such information, since the Ada grammar is highly ambiguous. For example, X(Y) might be a function_call or an indexed_component, and no context-free/syntactic information can tell the difference. It seems like we should view X(Y) as being, for example, “interpreted as a function_call” (if that's what overload resolution decides it is). Note that there are examples where the denotation of each usage name does not imply the syntactic category. However, even if that were not true, it seems that intuitively, the interpretation includes that information. Here's an example: 

Consider the declaration of Y (a complete context). In the above example, overload resolution can easily determine the declaration, and therefore the entity, denoted by Y, A, F, and I. However, given all of that information, we still don't know whether F(I) is a function_call or an indexed_component whose prefix is a function_call. (In the latter case, it is equivalent to F(7).all(I).)

It seems clear that the declaration of Y ought to be considered ambiguous. We describe that by saying that there are two interpretations, one as a function_call, and one as an indexed_component. These interpretations are both acceptable to the overloading rules. Therefore, the complete context is ambiguous, and therefore illegal.

It is the intent that the Ada 95 preference rule for root numeric operators is more locally enforceable than that of RM83-4.6(15). It should also eliminate interpretation shifts due to the addition or removal of a use_clause (the so called Beaujolais effect).

{AI95-00114-01} RM83-8.7 seems to be missing some complete contexts, such as pragma_argument_associations, declarative_items that are not declarations or aspect_clauses, and context_items. We have added these, and also replaced the “must be determinable” wording of RM83-5.4(3) with the notion that the expression of a case_statement is a complete context.

Cases like the Val attribute are now handled using the normal type resolution rules, instead of having special cases that explicitly allow things like “any integer type”. 

{AI95-00409-01} Ada 95 allowed name resolution to distinguish between anonymous access-to-variable and access-to-constant types. This is similar to distinguishing between subprograms with in and in out parameters, which is known to be bad. Thus, that part of the rule was dropped as we now have anonymous access-to-constant types, making this much more likely. 

If there is any code like this (such code should be rare), it will be ambiguous in Ada 2005. 

{AI95-00230-01} {AI95-00231-01} {AI95-00254-01} Generalized the anonymous access resolution rules to support the new capabilities of anonymous access types (that is, access-to-subprogram and access-to-constant).

{AI95-00382-01} We now allow the creation of self-referencing types via anonymous access types. This is an extension in unusual cases involving task and protected types. For example: 

{AI95-00332-01} Corrected the “single expected type” so that it works in contexts that don't have expected types (like object renames and qualified expressions). This fixes a hole in Ada 95 that appears to prohibit using aggregates, 'Access, character literals, string literals, and allocators in qualified expressions. 

{AI05-0149-1} Implicit conversion is now allowed from anonymous access-to-object types to general access-to-object types. Such conversions can make calls ambiguous. That can only happen when there are two visible subprograms with the same name and have profiles that differ only by a parameter that is of a named or anonymous access type, and the actual argument is of an anonymous access type. This should be rare, as many possible calls would be ambiguous even in Ada 2005 (including allocators and any actual of a named access type if the designated types are the same). 

{AI05-0149-1} Implicit conversion is allowed from anonymous access-to-object types to general access-to-object types if the designated type is convertible and runtime checks are minimized. See also the incompatibilities section.

{AI05-0102-1} Added a requirement here that implicit conversions are convertible to the appropriate type. This rule was scattered about the Reference Manual, we moved a single generalized version here. 

{AI12-0068-1} Corrigendum: Added a rule to specify that the current instance of a type or subtype is a value within an aspect_specification. This could be inconsistent if a predicate or invariant uses the Constrained attribute on the current instance (it will always be False now, while it might have returned True in original Ada 2012). More likely, a usage of a current instance as a prefix of an attribute will become illegal (such as Size or Alignment). Any such code is very tricky. Moreover, as this is a new feature of Ada 2012, there are not that many predicates and invariants, and the ones that exist are very unlikely to be this tricky. Thus we do not believe that there will be any practical effect to this change, other than to explicitly allow common implementation strategies. 

{AI12-0040-1} Corrigendum: Added wording to clarify that the selecting_expression of a case_expression is a complete context, just like that of a case_statement. Clearly, everyone expects these to work the same way. Moreover, since it would be a lot of extra work to treat case_expressions differently, it is quite unlikely that any compiler would implement the much more complicated resolution necessary (and we are not aware of any that did). Therefore, we didn't document this as a potential incompatibility.

{AI12-0125-3} Added a resolution rule for target_name (see 5.2.1).