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

Visibility Rules

The rules defining the scope of declarations and the rules defining which identifiers, character_literals, and operator_symbols are visible at (or from) various places in the text of the program are described in this section. The formulation of these rules uses the notion of a declarative region.
As explained in section Declarations and Types, a declaration declares a view of an entity and associates a defining name with that view. The view comprises an identification of the viewed entity, and possibly additional properties. A usage name denotes a declaration. It also denotes the view declared by that declaration, and denotes the entity of that view. Thus, two different usage names might denote two different views of the same entity; in this case they denote the same entity.

Declarative Region

Static Semantics

For each of the following constructs, there is a portion of the program text called its declarative region, within which nested declarations can occur:
1. any declaration, other than that of an enumeration type, that is not a completion of a previous declaration;
2. a block_statement;
3. a loop_statement;
4. an accept_statement;
5. an exception_handler.

The declarative region includes the text of the construct together with additional text determined (recursively), as follows:
1. If a declaration is included, so is its completion, if any.
2. If the declaration of a library unit (including Standard -- See section Compilation Units - Library Units, is included, so are the declarations of any child units (and their completions, by the previous rule). The child declarations occur after the declaration.
3. If a body_stub is included, so is the corresponding subunit.
4. If a type_declaration is included, then so is a corresponding record_representation_clause, if any.

The declarative region of a declaration is also called the declarative region of any view or entity declared by the declaration.
A declaration occurs immediately within a declarative region if this region is the innermost declarative region that encloses the declaration (the immediately enclosing declarative region), not counting the declarative region (if any) associated with the declaration itself.
A declaration is local to a declarative region if the declaration occurs immediately within the declarative region. An entity is local to a declarative region if the entity is declared by a declaration that is local to the declarative region.
A declaration is global to a declarative region if the declaration occurs immediately within another declarative region that encloses the declarative region. An entity is global to a declarative region if the entity is declared by a declaration that is global to the declarative region. NOTES
(1) The children of a parent library unit are inside the parent's declarative region, even though they do not occur inside the parent's declaration or body. This implies that one can use (for example) "P.Q" to refer to a child of P whose defining name is Q, and that after "use P;" Q can refer (directly) to that child.
(2) As explained above and in section Compilation Units - Library Units, all library units are descendants of Standard, and so are contained in the declarative region of Standard. They are not inside the declaration or body of Standard, but they are inside its declarative region.
(3) For a declarative region that comes in multiple parts, the text of the declarative region does not contain any text that might appear between the parts. Thus, when a portion of a declarative region is said to extend from one place to another in the declarative region, the portion does not contain any text that might appear between the parts of the declarative region.

Scope of Declarations

For each declaration, the language rules define a certain portion of the program text called the scope of the declaration. The scope of a declaration is also called the scope of any view or entity declared by the declaration. Within the scope of an entity, and only there, there are places where it is legal to refer to the declared entity. These places are defined by the rules of visibility and overloading. Static Semantics
The immediate scope of a declaration is a portion of the declarative region immediately enclosing the declaration. The immediate scope starts at the beginning of the declaration, except in the case of an overloadable declaration, in which case the immediate scope starts just after the place where the profile of the callable entity is determined (which is at the end of the _specification for the callable entity, or at the end of the generic_instantiation if an instance). The immediate scope extends to the end of the declarative region, with the following exceptions:
1. The immediate scope of a library_item includes only its semantic dependents.
2. The immediate scope of a declaration in the private part of a library unit does not include the visible part of any public descendant of that library unit.

The visible part of (a view of) an entity is a portion of the text of its declaration containing declarations that are visible from outside. The private part of (a view of) an entity that has a visible part contains all declarations within the declaration of (the view of) the entity, except those in the visible part; these are not visible from outside. Visible and private parts are defined only for these kinds of entities: callable entities, other program units, and composite types.
1. The visible part of a view of a callable entity is its profile.
2. The visible part of a composite type other than a task or protected type consists of the declarations of all components declared (explicitly or implicitly) within the type_declaration.
3. The visible part of a generic unit includes the generic_formal_part. For a generic package, it also includes the first list of basic_declarative_items of the package_specification. For a generic subprogram, it also includes the profile.
4. The visible part of a package, task unit, or protected unit consists of declarations in the program unit's declaration other than those following the reserved word private, if any; See section Package Specifications and Declarations, and See section Formal Packages, for packages, see section Task Units and Task Objects, for task units, and section Protected Units and Protected Objects, for protected units.

The scope of a declaration always contains the immediate scope of the declaration. In addition, for a given declaration that occurs immediately within the visible part of an outer declaration, or is a public child of an outer declaration, the scope of the given declaration extends to the end of the scope of the outer declaration, except that the scope of a library_item includes only its semantic dependents.
The immediate scope of a declaration is also the immediate scope of the entity or view declared by the declaration. Similarly, the scope of a declaration is also the scope of the entity or view declared by the declaration. NOTES
(4) There are notations for denoting visible declarations that are not directly visible. For example, parameter_specifications are in the visible part of a subprogram_declaration so that they can be used in named-notation calls appearing outside the called subprogram. For another example, declarations of the visible part of a package can be denoted by expanded names appearing outside the package, and can be made directly visible by a use_clause.

Visibility

The visibility rules, given below, determine which declarations are visible and directly visible at each place within a program. The visibility rules apply to both explicit and implicit declarations. Static Semantics
A declaration is defined to be directly visible at places where a name consisting of only an identifier or operator_symbol is sufficient to denote the declaration; that is, no selected_component notation or special context (such as preceding => in a named association) is necessary to denote the declaration. A declaration is defined to be visible wherever it is directly visible, as well as at other places where some name (such as a selected_component) can denote the declaration.
The syntactic category direct_name is used to indicate contexts where direct visibility is required. The syntactic category selector_name is used to indicate contexts where visibility, but not direct visibility, is required.
There are two kinds of direct visibility: immediate visibility and use-visibility. A declaration is immediately visible at a place if it is directly visible because the place is within its immediate scope. A declaration is use-visible if it is directly visible because of a use_clause, see section Use Clauses. Both conditions can apply.
A declaration can be hidden, either from direct visibility, or from all visibility, within certain parts of its scope. Where hidden from all visibility, it is not visible at all (neither using a direct_name nor a selector_name). Where hidden from direct visibility, only direct visibility is lost; visibility using a selector_name is still possible.
Two or more declarations are overloaded if they all have the same defining name and there is a place where they are all directly visible.
The declarations of callable entities (including enumeration literals) are overloadable, meaning that overloading is allowed for them.
Two declarations are homographs if they have the same defining name, and, if both are overloadable, their profiles are type conformant. An inner declaration hides any outer homograph from direct visibility.
Two homographs are not generally allowed immediately within the same declarative region unless one overrides the other (see Legality Rules below). A declaration overrides another homograph that occurs immediately within the same declarative region in the following cases:
1. An explicit declaration overrides an implicit declaration of a primitive subprogram, regardless of which declaration occurs first;
2. The implicit declaration of an inherited operator overrides that of a predefined operator;
3. An implicit declaration of an inherited subprogram overrides a previous implicit declaration of an inherited subprogram.
4. For an implicit declaration of a primitive subprogram in a generic unit, there is a copy of this declaration in an instance. However, a whole new set of primitive subprograms is implicitly declared for each type declared within the visible part of the instance. These new declarations occur immediately after the type declaration, and override the copied ones. The copied ones can be called only from within the instance; the new ones can be called only from outside the instance, although for tagged types, the body of a new one can be executed by a call to an old one.

A declaration is visible within its scope, except where hidden from all visibility, as follows:
1. An overridden declaration is hidden from all visibility within the scope of the overriding declaration.
2. A declaration is hidden from all visibility until the end of the declaration, except:
  1. For a record type or record extension, the declaration is hidden from all visibility only until the reserved word record;
  2. For a package_declaration, task declaration, protected declaration, generic_package_declaration, or subprogram_body, the declaration is hidden from all visibility only until the reserved word is of the declaration.

If the completion of a declaration is a declaration, then within the scope of the completion, the first declaration is hidden from all visibility. Similarly, a discriminant_specification or parameter_specification is hidden within the scope of a corresponding discriminant_specification or parameter_specification of a corresponding completion, or of a corresponding accept_statement.
The declaration of a library unit (including a library_unit_renaming_declaration) is hidden from all visibility except at places that are within its declarative region or within the scope of a with_clause that mentions it. For each declaration or renaming of a generic unit as a child of some parent generic package, there is a corresponding declaration nested immediately within each instance of the parent. Such a nested declaration is hidden from all visibility except at places that are within the scope of a with_clause that mentions the child.

A declaration with a defining_identifier or defining_operator_symbol is immediately visible (and hence directly visible) within its immediate scope except where hidden from direct visibility, as follows:
1. A declaration is hidden from direct visibility within the immediate scope of a homograph of the declaration, if the homograph occurs within an inner declarative region;
2. A declaration is also hidden from direct visibility where hidden from all visibility.

Name Resolution Rules

A direct_name shall resolve to denote a directly visible declaration whose defining name is the same as the direct_name. A selector_name shall resolve to denote a visible declaration whose defining name is the same as the selector_name.
These rules on visibility and direct visibility do not apply in a context_clause, a parent_unit_name, or a pragma that appears at the place of a compilation_unit. For those contexts, see the rules in See section Environment-Level Visibility Rules. Legality Rules
An explicit declaration is illegal if there is a homograph occurring immediately within the same declarative region that is visible at the place of the declaration, and is not hidden from all visibility by the explicit declaration. Similarly, the context_clause for a subunit is illegal if it mentions (in a with_clause) some library unit, and there is a homograph of the library unit that is visible at the place of the corresponding stub, and the homograph and the mentioned library unit are both declared immediately within the same declarative region. These rules also apply to dispatching operations declared in the visible part of an instance of a generic unit. However, they do not apply to other overloadable declarations in an instance; such declarations may have type conformant profiles in the instance, so long as the corresponding declarations in the generic were not type conformant. NOTES
(5) Visibility for compilation units follows from the definition of the environment in section The Compilation Process, except that it is necessary to apply a with_clause to obtain visibility to a library_unit_declaration or library_unit_renaming_declaration.
(6) In addition to the visibility rules given above, the meaning of the occurrence of a direct_name or selector_name at a given place in the text can depend on the overloading rules, see section The Context of Overload Resolution.
(7) Not all contexts where an identifier, character_literal, or operator_symbol are allowed require visibility of a corresponding declaration. Contexts where visibility is not required are identified by using one of these three syntactic categories directly in a syntax rule, rather than using direct_name or selector_name.

Use Clauses

A use_package_clause achieves direct visibility of declarations that appear in the visible part of a package; a use_type_clause achieves direct visibility of the primitive operators of a type. Syntax

use_clause ::= use_package_clause | use_type_clause

use_package_clause ::= use package_name {, package_name};

use_type_clause ::= use type subtype_mark {, subtype_mark};

Legality Rules

A package_name of a use_package_clause shall denote a package. Static Semantics
For each use_clause, there is a certain region of text called the scope of the use_clause. For a use_clause within a context_clause of a library_unit_declaration or library_unit_renaming_declaration, the scope is the entire declarative region of the declaration. For a use_clause within a context_clause of a body, the scope is the entire body and any subunits (including multiply nested subunits). The scope does not include context_clauses themselves.
For a use_clause immediately within a declarative region, the scope is the portion of the declarative region starting just after the use_clause and extending to the end of the declarative region. However, the scope of a use_clause in the private part of a library unit does not include the visible part of any public descendant of that library unit.
For each package denoted by a package_name of a use_package_clause whose scope encloses a place, each declaration that occurs immediately within the declarative region of the package is potentially use-visible at this place if the declaration is visible at this place. For each type T or T'Class determined by a subtype_mark of a use_type_clause whose scope encloses a place, the declaration of each primitive operator of type T is potentially use-visible at this place if its declaration is visible at this place.
A declaration is use-visible if it is potentially use-visible, except in these naming-conflict cases:
1. A potentially use-visible declaration is not use-visible if the place considered is within the immediate scope of a homograph of the declaration.
2. Potentially use-visible declarations that have the same identifier are not use-visible unless each of them is an overloadable declaration.

Dynamic Semantics

The elaboration of a use_clause has no effect. Examples
Example of a use clause in a context clause:
```
with Ada.Calendar; use Ada;
```
```
Example of a use type clause:
```

use type Rational_Numbers.Rational;  --  see section Package Specifications and Declarations
Two_Thirds: Rational_Numbers.Rational := 2/3;

Renaming Declarations

A renaming_declaration declares another name for an entity, such as an object, exception, package, subprogram, entry, or generic unit. Alternatively, a subprogram_renaming_declaration can be the completion of a previous subprogram_declaration. Syntax

renaming_declaration ::=
      object_renaming_declaration
    | exception_renaming_declaration
    | package_renaming_declaration
    | subprogram_renaming_declaration
    | generic_renaming_declaration

Dynamic Semantics

The elaboration of a renaming_declaration evaluates the name that follows the reserved word renames and thereby determines the view and entity denoted by this name (the renamed view and renamed entity). A name that denotes the renaming_declaration denotes (a new view of) the renamed entity. NOTES
(8) Renaming may be used to resolve name conflicts and to act as a shorthand. Renaming with a different identifier or operator_symbol does not hide the old name; the new name and the old name need not be visible at the same places.
(9) A task or protected object that is declared by an explicit object_declaration can be renamed as an object. However, a single task or protected object cannot be renamed since the corresponding type is anonymous (meaning it has no nameable subtypes). For similar reasons, an object of an anonymous array or access type cannot be renamed.
(10) A subtype defined without any additional constraint can be used to achieve the effect of renaming another subtype (including a task or protected subtype) as in
```
subtype Mode is Ada.Text_IO.File_Mode;
```

Object Renaming Declarations

An object_renaming_declaration is used to rename an object. Syntax

object_renaming_declaration ::=
   defining_identifier : subtype_mark renames object_name;

Name Resolution Rules

The type of the object_name shall resolve to the type determined by the subtype_mark. Legality Rules
The renamed entity shall be an object.
The renamed entity shall not be a subcomponent that depends on discriminants of a variable whose nominal subtype is unconstrained, unless this subtype is indefinite, or the variable is aliased. A slice of an array shall not be renamed if this restriction disallows renaming of the array. Static Semantics
An object_renaming_declaration declares a new view of the renamed object whose properties are identical to those of the renamed view. Thus, the properties of the renamed object are not affected by the renaming_declaration. In particular, its value and whether or not it is a constant are unaffected; similarly, the constraints that apply to an object are not affected by renaming (any constraint implied by the subtype_mark of the object_renaming_declaration is ignored). Examples
Example of renaming an object:

declare
   L : Person renames Leftmost_Person;  --  see section Incomplete Type Declarations
begin
   L.Age := L.Age + 1;
end;

Exception Renaming Declarations

An exception_renaming_declaration is used to rename an exception. Syntax

exception_renaming_declaration ::=
   defining_identifier : exception renames exception_name;

Legality Rules

The renamed entity shall be an exception. Static Semantics
An exception_renaming_declaration declares a new view of the renamed exception. Examples
Example of renaming an exception:

EOF : exception renames Ada.IO_Exceptions.End_Error;
--  see section Exceptions in Input-Output

Package Renaming Declarations

A package_renaming_declaration is used to rename a package. Syntax

package_renaming_declaration ::=
   package defining_program_unit_name renames package_name;

Legality Rules

The renamed entity shall be a package. Static Semantics
A package_renaming_declaration declares a new view of the renamed package. Examples
Example of renaming a package:
```
package TM renames Table_Manager;
```

Subprogram Renaming Declarations

A subprogram_renaming_declaration can serve as the completion of a subprogram_declaration; such a renaming_declaration is called a renaming-as-body. A subprogram_renaming_declaration that is not a completion is called a renaming-as-declaration, and is used to rename a subprogram (possibly an enumeration literal) or an entry. Syntax

subprogram_renaming_declaration ::=
   subprogram_specification renames callable_entity_name;

Name Resolution Rules

The expected profile for the callable_entity_name is the profile given in the subprogram_specification. Legality Rules
The profile of a renaming-as-declaration shall be mode-conformant with that of the renamed callable entity.
The profile of a renaming-as-body shall be subtype-conformant with that of the renamed callable entity, and shall conform fully to that of the declaration it completes. If the renaming-as-body completes that declaration before the subprogram it declares is frozen, the subprogram it declares takes its convention from the renamed subprogram; otherwise the convention of the renamed subprogram shall not be Intrinsic.
A name that denotes a formal parameter of the subprogram_specification is not allowed within the callable_entity_name. Static Semantics
A renaming-as-declaration declares a new view of the renamed entity. The profile of this new view takes its subtypes, parameter modes, and calling convention from the original profile of the callable entity, while taking the formal parameter names and default_expressions from the profile given in the subprogram_renaming_declaration. The new view is a function or procedure, never an entry. Dynamic Semantics
For a call on a renaming of a dispatching subprogram that is overridden, if the overriding occurred before the renaming, then the body executed is that of the overriding declaration, even if the overriding declaration is not visible at the place of the renaming; otherwise, the inherited or predefined subprogram is called. NOTES
(11) A procedure can only be renamed as a procedure. A function whose defining_designator is either an identifier or an operator_symbol can be renamed with either an identifier or an operator_symbol; for renaming as an operator, the subprogram specification given in the renaming_declaration is subject to the rules given in section Overloading of Operators, for operator declarations. Enumeration literals can be renamed as functions; similarly, attribute_references that denote functions (such as references to Succ and Pred) can be renamed as functions. An entry can only be renamed as a procedure; the new name is only allowed to appear in contexts that allow a procedure name. An entry of a family can be renamed, but an entry family cannot be renamed as a whole.
(12) The operators of the root numeric types cannot be renamed because the types in the profile are anonymous, so the corresponding specifications cannot be written; the same holds for certain attributes, such as Pos.
(13) Calls with the new name of a renamed entry are procedure_call_statements and are not allowed at places where the syntax requires an entry_call_statement in conditional_ and timed_entry_calls, nor in an asynchronous_select; similarly, the Count attribute is not available for the new name.
(14) The primitiveness of a renaming-as-declaration is determined by its profile, and by where it occurs, as for any declaration of (a view of) a subprogram; primitiveness is not determined by the renamed view. In order to perform a dispatching call, the subprogram name has to denote a primitive subprogram, not a non-primitive renaming of a primitive subprogram. Examples
Examples of subprogram renaming declarations:

procedure My_Write(C : in Character) renames Pool(K).Write;
--  see section Selected Components

function Real_Plus(Left, Right : Real   ) return Real    renames "+";
function Int_Plus (Left, Right : Integer) return Integer renames "+";

function Rouge return Color renames Red;  --  see section Enumeration Types
function Rot   return Color renames Red;
function Rosso return Color renames Rouge;

function Next(X : Color) return Color renames Color'Succ;
--  see section Enumeration Types

Example of a subprogram renaming declaration with new parameter names:

function "*" (X,Y : Vector) return Real renames Dot_Product;
--  see section Subprogram Declarations

Example of a subprogram renaming declaration with a new default expression:

function Minimum(L : Link := Head) return Cell renames Min_Cell;
--  see section Subprogram Declarations

Generic Renaming Declarations

Syntax

generic_renaming_declaration ::=
    generic package defining_program_unit_name renames
      generic_package_name;
  | generic procedure defining_program_unit_name renames
      generic_procedure_name;
  | generic function defining_program_unit_name renames
      generic_function_name;

Legality Rules

The renamed entity shall be a generic unit of the corresponding kind. Static Semantics
A generic_renaming_declaration declares a new view of the renamed generic unit. NOTES
(15) Although the properties of the new view are the same as those of the renamed view, the place where the generic_renaming_declaration occurs may affect the legality of subsequent renamings and instantiations that denote the generic_renaming_declaration, in particular if the renamed generic unit is a library unit, see section Compilation Units - Library Units. Examples
Example of renaming a generic unit:

generic package Enum_IO renames Ada.Text_IO.Enumeration_IO;
--  see section Input-Output for Enumeration Types

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 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 contexts.
The syntax rules of the language and the visibility rules given in See section 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
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.

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.

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:
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 Generic Instantiation.

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:
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 Access Types, 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. Legality Rules
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 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. NOTES
(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).

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