Section 8: Visibility Rules
1 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.
2 As explained in Section 3, 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.
8.1 Declarative Region
Static Semantics
1 For each of the following constructs, there is a portion of the program
text called its declarative region, within which nested declarations can
occur:
2 * any declaration, other than that of an enumeration type, that is not a
completion of a previous declaration;
3 * a block_statement;
4 * a loop_statement;
4.1/2 * an extended_return_statement;
5 * an accept_statement;
6 * an exception_handler.
7 The declarative region includes the text of the construct together with
additional text determined (recursively), as follows:
8 * If a declaration is included, so is its completion, if any.
9 * If the declaration of a library unit (including Standard - see
10.1.1) is included, so are the declarations of any child units (and
their completions, by the previous rule). The child declarations occur
after the declaration.
10 * If a body_stub is included, so is the corresponding subunit.
11 * If a type_declaration is included, then so is a corresponding
record_representation_clause, if any.
12 The declarative region of a declaration is also called the declarative
region of any view or entity declared by the declaration.
13 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.
14 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.
15 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
16 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.
17 2 As explained above and in 10.1.1, "
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.
18 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.
8.2 Scope of Declarations
1 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
2 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:
3 * The immediate scope of a library_item includes only its semantic
dependents.
4 * 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.
5 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.
6 * The visible part of a view of a callable entity is its profile.
7 * 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.
8 * 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.
9 * 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 7.1 and 12.7 for
packages, 9.1 for task units, and 9.4 for protected units.
10 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.
10.1/2 The scope of an attribute_definition_clause is identical to the scope
of a declaration that would occur at the point of the
attribute_definition_clause.
11 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
12 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.
8.3 Visibility
1 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
2 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.
3 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.
4 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 8.4). Both conditions can apply.
5 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.
6 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.
7 The declarations of callable entities (including enumeration literals) are
overloadable, meaning that overloading is allowed for them.
8 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.
9/1 Two homographs are not generally allowed immediately within the same
declarative region unless one overrides the other (see Legality Rules below).
The only declarations that are overridable are the implicit declarations for
predefined operators and inherited primitive subprograms. A declaration
overrides another homograph that occurs immediately within the same
declarative region in the following cases:
10/1 * A declaration that is not overridable overrides one that is
overridable, regardless of which declaration occurs first;
11 * The implicit declaration of an inherited operator overrides that of a
predefined operator;
12 * An implicit declaration of an inherited subprogram overrides a
previous implicit declaration of an inherited subprogram.
12.1/2 * If two or more homographs are implicitly declared at the same place:
12.2/2 * If at least one is a subprogram that is neither a null procedure
nor an abstract subprogram, and does not require overriding (see
3.9.3), then they override those that are null procedures,
abstract subprograms, or require overriding. If more than one such
homograph remains that is not thus overridden, then they are all
hidden from all visibility.
12.3/2 * Otherwise (all are null procedures, abstract subprograms, or
require overriding), then any null procedure overrides all
abstract subprograms and all subprograms that require overriding;
if more than one such homograph remains that is not thus
overridden, then if they are all fully conformant with one
another, one is chosen arbitrarily; if not, they are all hidden
from all visibility.
13 * 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.
14 A declaration is visible within its scope, except where hidden from all
visibility, as follows:
15 * An overridden declaration is hidden from all visibility within the
scope of the overriding declaration.
16 * A declaration is hidden from all visibility until the end of the
declaration, except:
17 * For a record type or record extension, the declaration is hidden
from all visibility only until the reserved word record;
18/2 * For a package_declaration, generic_package_declaration, or
subprogram_body, the declaration is hidden from all visibility
only until the reserved word is of the declaration;
18.1/2 * For a task declaration or protected declaration, the declaration
is hidden from all visibility only until the reserved word with of
the declaration if there is one, or the reserved word is of the
declaration if there is no with.
19 * 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.
20/2 * The declaration of a library unit (including a
library_unit_renaming_declaration) is hidden from all visibility at
places outside its declarative region that are not within the scope of
a nonlimited_with_clause that mentions it. The limited view of a
library package is hidden from all visibility at places that are not
within the scope of a limited_with_clause that mentions it; in
addition, the limited view is hidden from all visibility within the
declarative region of the package, as well as within the scope of any
nonlimited_with_clause that mentions the package. Where the
declaration of the limited view of a package is visible, any name that
denotes the package denotes the limited view, including those provided
by a package renaming.
20.1/2 * 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.
21 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:
22 * 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;
23 * A declaration is also hidden from direct visibility where hidden from
all visibility.
23.1/2 An attribute_definition_clause is visible everywhere within its scope.
Name Resolution Rules
24 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.
25 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 10.1.6, "
Environment-Level Visibility Rules".
Legality Rules
26/2 A non-overridable 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
non-overridable declaration. In addition, a type extension is illegal if
somewhere within its immediate scope it has two visible components with the
same name. Similarly, the context_clause for a compilation unit 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 compilation unit, 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
27 5 Visibility for compilation units follows from the definition of the
environment in 10.1.4, except that it is necessary to apply a
with_clause to obtain visibility to a library_unit_declaration or
library_unit_renaming_declaration.
28 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 8.6).
29 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.
8.3.1 Overriding Indicators
1/2 An overriding_indicator is used to declare that an operation is intended
to override (or not override) an inherited operation.
Syntax
2/2 overriding_indicator ::= [not] overriding
Legality Rules
3/2 If an abstract_subprogram_declaration, null_procedure_declaration,
subprogram_body, subprogram_body_stub, subprogram_renaming_declaration,
generic_instantiation of a subprogram, or subprogram_declaration other than a
protected subprogram has an overriding_indicator, then:
4/2 * the operation shall be a primitive operation for some type;
5/2 * if the overriding_indicator is overriding, then the operation shall
override a homograph at the place of the declaration or body;
6/2 * if the overriding_indicator is not overriding, then the operation
shall not override any homograph (at any place).
7/2 In addition to the places where Legality Rules normally apply, these rules
also apply in the private part of an instance of a generic unit.
NOTES
8/2 8 Rules for overriding_indicators of task and protected entries and
of protected subprograms are found in 9.5.2 and 9.4, respectively.
Examples
9/2 The use of overriding_indicators allows the detection of errors at
compile-time that otherwise might not be detected at all. For instance, we
might declare a security queue derived from the Queue interface of 3.9.4 as:
10/2 type Security_Queue is new Queue with record ...;
11/2 overriding
procedure Append(Q : in out Security_Queue; Person : in Person_Name);
12/2 overriding
procedure Remove_First(Q : in out Security_Queue; Person : in Person_Name);
13/2 overriding
function Cur_Count(Q : in Security_Queue) return Natural;
14/2 overriding
function Max_Count(Q : in Security_Queue) return Natural;
15/2 not overriding
procedure Arrest(Q : in out Security_Queue; Person : in Person_Name);
16/2 The first four subprogram declarations guarantee that these subprograms
will override the four subprograms inherited from the Queue interface. A
misspelling in one of these subprograms will be detected by the
implementation. Conversely, the declaration of Arrest guarantees that this is
a new operation.
8.4 Use Clauses
1 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
2 use_clause ::= use_package_clause | use_type_clause
3 use_package_clause ::= use package_name {, package_name};
4 use_type_clause ::= use type subtype_mark {, subtype_mark};
Legality Rules
5/2 A package_name of a use_package_clause shall denote a nonlimited view of a
package.
Static Semantics
6 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.
7 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.
7.1/2 A package is named in a use_package_clause if it is denoted by a
package_name of that clause. A type is named in a use_type_clause if it is determined
by a subtype_mark of that clause.
8/2 For each package named in 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 named in 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.
9 A declaration is use-visible if it is potentially use-visible, except in
these naming-conflict cases:
10 * A potentially use-visible declaration is not use-visible if the place
considered is within the immediate scope of a homograph of the
declaration.
11 * Potentially use-visible declarations that have the same identifier are
not use-visible unless each of them is an overloadable declaration.
Dynamic Semantics
12 The elaboration of a use_clause has no effect.
Examples
13 Example of a use clause in a context clause:
14 with Ada.Calendar; use Ada;
15 Example of a use type clause:
16 use type Rational_Numbers.Rational; -- see 7.1
Two_Thirds: Rational_Numbers.Rational := 2/3;
8.5 Renaming Declarations
1 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
2 renaming_declaration ::=
object_renaming_declaration
| exception_renaming_declaration
| package_renaming_declaration
| subprogram_renaming_declaration
| generic_renaming_declaration
Dynamic Semantics
3 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
4 9 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.
5 10 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.
6 11 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
7 subtype Mode is Ada.Text_IO.File_Mode;
8.5.1 Object Renaming Declarations
1 An object_renaming_declaration is used to rename an object.
Syntax
2/2 object_renaming_declaration ::=
defining_identifier : [null_exclusion] subtype_mark
renames object_name;
| defining_identifier : access_definition renames object_name;
Name Resolution Rules
3/2 The type of the object_name shall resolve to the type determined by the
subtype_mark, or in the case where the type is defined by an
access_definition, to an anonymous access type. If the anonymous access type
is an access-to-object type, the type of the object_name shall have the same
designated type as that of the access_definition. If the anonymous access type
is an access-to-subprogram type, the type of the object_name shall have a
designated profile that is type conformant with that of the
access_definition.
Legality Rules
4 The renamed entity shall be an object.
4.1/2 In the case where the type is defined by an access_definition, the type
of the renamed object and the type defined by the access_definition:
4.2/2 * shall both be access-to-object types with statically matching
designated subtypes and with both or neither being access-to-constant
types; or
4.3/2 * shall both be access-to-subprogram types with subtype conformant
designated profiles.
4.4/2 For an object_renaming_declaration with a null_exclusion or an
access_definition that has a null_exclusion:
4.5/2 * if the object_name denotes a generic formal object of a generic unit
G, and the object_renaming_declaration occurs within the body of G or
within the body of a generic unit declared within the declarative
region of G, then the declaration of the formal object of G shall have
a null_exclusion;
4.6/2 * otherwise, the subtype of the object_name shall exclude null. In
addition to the places where Legality Rules normally apply (see 12.3
), this rule applies also in the private part of an instance of a
generic unit.
5/2 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 constrained by its initial
value. A slice of an array shall not be renamed if this restriction disallows
renaming of the array. In addition to the places where Legality Rules normally
apply, these rules apply also in the private part of an instance of a generic
unit. These rules also apply for a renaming that appears in the body of a
generic unit, with the additional requirement that even if the nominal subtype
of the variable is indefinite, its type shall not be a descendant of an
untagged generic formal derived type.
Static Semantics
6/2 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 null exclusion or constraints that
apply to an object are not affected by renaming (any constraint implied by the
subtype_mark or access_definition of the object_renaming_declaration is
ignored).
Examples
7 Example of renaming an object:
8 declare
L : Person renames Leftmost_Person; -- see 3.10.1
begin
L.Age := L.Age + 1;
end;
8.5.2 Exception Renaming Declarations
1 An exception_renaming_declaration is used to rename an exception.
Syntax
2 exception_renaming_declaration ::= defining_identifier
: exception renames exception_name;
Legality Rules
3 The renamed entity shall be an exception.
Static Semantics
4 An exception_renaming_declaration declares a new view of the renamed
exception.
Examples
5 Example of renaming an exception:
6 EOF : exception renames Ada.IO_Exceptions.End_Error; -- see A.13
8.5.3 Package Renaming Declarations
1 A package_renaming_declaration is used to rename a package.
Syntax
2 package_renaming_declaration ::= package defining_program_unit_name
renames package_name;
Legality Rules
3 The renamed entity shall be a package.
3.1/2 If the package_name of a package_renaming_declaration denotes a limited
view of a package P, then a name that denotes the
package_renaming_declaration shall occur only within the immediate scope of
the renaming or the scope of a with_clause that mentions the package P or, if
P is a nested package, the innermost library package enclosing P.
Static Semantics
4 A package_renaming_declaration declares a new view of the renamed package.
4.1/2 At places where the declaration of the limited view of the renamed
package is visible, a name that denotes the package_renaming_declaration
denotes a limited view of the package (see 10.1.1).
Examples
5 Example of renaming a package:
6 package TM renames Table_Manager;
8.5.4 Subprogram Renaming Declarations
1 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
2/2 subprogram_renaming_declaration ::=
[overriding_indicator]
subprogram_specification renames callable_entity_name;
Name Resolution Rules
3 The expected profile for the callable_entity_name is the profile given in
the subprogram_specification.
Legality Rules
4 The profile of a renaming-as-declaration shall be mode-conformant with
that of the renamed callable entity.
4.1/2 For a parameter or result subtype of the subprogram_specification that
has an explicit null_exclusion:
4.2/2 * if the callable_entity_name denotes a generic formal subprogram of a
generic unit G, and the subprogram_renaming_declaration occurs within
the body of a generic unit G or within the body of a generic unit
declared within the declarative region of the generic unit G, then the
corresponding parameter or result subtype of the formal subprogram of
G shall have a null_exclusion;
4.3/2 * otherwise, the subtype of the corresponding parameter or result type
of the renamed callable entity shall exclude null. In addition to the
places where Legality Rules normally apply (see 12.3), this rule
applies also in the private part of an instance of a generic unit.
5/1 The profile of a renaming-as-body 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 profile shall be
mode-conformant with that of the renamed callable entity and the subprogram it
declares takes its convention from the renamed subprogram; otherwise, the
profile shall be subtype-conformant with that of the renamed callable entity
and the convention of the renamed subprogram shall not be Intrinsic. A
renaming-as-body is illegal if the declaration occurs before the subprogram
whose declaration it completes is frozen, and the renaming renames the
subprogram itself, through one or more subprogram renaming declarations, none
of whose subprograms has been frozen.
5.1/2 The callable_entity_name of a renaming shall not denote a subprogram
that requires overriding (see 3.9.3).
5.2/2 The callable_entity_name of a renaming-as-body shall not denote an
abstract subprogram.
6 A name that denotes a formal parameter of the subprogram_specification is
not allowed within the callable_entity_name.
Static Semantics
7 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
7.1/1 For a call to a subprogram whose body is given as a renaming-as-body,
the execution of the renaming-as-body is equivalent to the execution of a
subprogram_body that simply calls the renamed subprogram with its formal
parameters as the actual parameters and, if it is a function, returns the
value of the call.
8 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.
Bounded (Run-Time) Errors
8.1/1 If a subprogram directly or indirectly renames itself, then it is a
bounded error to call that subprogram. Possible consequences are that
Program_Error or Storage_Error is raised, or that the call results in infinite
recursion.
NOTES
9 12 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 6.6 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.
10 13 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.
11 14 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.
12 15 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
13 Examples of subprogram renaming declarations:
14 procedure My_Write(C : in Character) renames Pool(K).Write; -- see 4.1.3
15 function Real_Plus(Left, Right : Real ) return Real renames "+";
function Int_Plus (Left, Right : Integer) return Integer renames "+";
16 function Rouge return Color renames Red; -- see 3.5.1
function Rot return Color renames Red;
function Rosso return Color renames Rouge;
17 function Next(X : Color) return Color renames Color'Succ; -- see 3.5.1
18 Example of a subprogram renaming declaration with new parameter names:
19 function "*" (X,Y : Vector) return Real renames Dot_Product; -- see 6.1
20 Example of a subprogram renaming declaration with a new default
expression:
21 function Minimum(L : Link := Head) return Cell renames Min_Cell; -- see 6.1
8.5.5 Generic Renaming Declarations
1 A generic_renaming_declaration is used to rename a generic unit.
Syntax
2 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
3 The renamed entity shall be a generic unit of the corresponding kind.
Static Semantics
4 A generic_renaming_declaration declares a new view of the renamed generic
unit.
NOTES
5 16 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 10.1.1
).
Examples
6 Example of renaming a generic unit:
7 generic package Enum_IO renames Ada.Text_IO.Enumeration_IO; -- see A.10.10
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 * A context_item.
6 * A declarative_item or declaration.
7 * A statement.
8 * A pragma_argument_association.
9 * The expression of a case_statement.
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 * for each constituent of the complete context, to which syntactic
categories it belongs, and by which syntax rules; and
12 * for each usage name, which declaration it denotes (and, therefore,
which view and which entity it denotes); and
13 * 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.
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/2 * 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. This rule does not apply if the usage name appears within the
subtype_mark of an access_definition for an access-to-object type, or
within the subtype of a parameter or result of an access-to-subprogram
type.
18 * 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.
19 A usage name that denotes a view also denotes the entity of that view.
20/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 literals,
dispatching operations, and anonymous access types:
21 * 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.
22 * If the expected type for a construct is a specific type T, then the
type of the construct shall resolve either to T, or:
23 * to T'Class; or
24 * to a universal type that covers T; or
25/2 * when T is a specific anonymous access-to-object type (see 3.10)
with designated type D, to an access-to-object type whose
designated type is D'Class or is covered by D; or
25.1/2 * when T is an anonymous access-to-subprogram type (see 3.10), to an
access-to-subprogram type whose designated profile is
type-conformant with that of T.
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/2 When a construct is one that requires that its expected type be a single
type in a given class, the type of 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. 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.
NOTES
33 17 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.
34 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).
Generated by dwww version 1.15 on Wed May 22 06:44:52 CEST 2024.