|
DataMuseum.dkPresents historical artifacts from the history of: Rational R1000/400 Tapes |
This is an automatic "excavation" of a thematic subset of
See our Wiki for more about Rational R1000/400 Tapes Excavated with: AutoArchaeologist - Free & Open Source Software. |
top - metrics - downloadIndex: C T
Length: 39536 (0x9a70)
Types: TextFile
Names: »CHAPTER_8«
└─⟦180fe333a⟧ Bits:30000405 8mm tape, Rational 1000, SW CATALOG, 10_20_0
└─⟦180fe333a⟧ Bits:30000537 8mm tape, Rational 1000, SW Catalog 10_20_0
└─⟦5cb1d1d7f⟧ »DATA«
└─⟦3b1ee7bd8⟧
└─⟦this⟧
8. Visibility Rules
The rules defining the scope of declarations and the rules defining which
identifiers are visible at various points in the text of the program are
described in this chapter. The formulation of these rules uses the notion
of a declarative region.
References: declaration 3.1, declarative region 8.1, identifier 2.3, scope
8.2, visibility 8.3
8.1 Declarative Region
A declarative region is a portion of the program text. A single
declarative region is formed by the text of each of the following:
- A subprogram declaration, a package declaration, a task declaration,
or a generic declaration, together with the corresponding body, if
any. If the body is a body stub, the declarative region also includes
the corresponding subunit. If the program unit has subunits, they are
also included.
- An entry declaration together with the corresponding accept
statements.
- A record type declaration, together with a corresponding private or
incomplete type declaration if any, and together with a corresponding
record representation clause if any.
- A renaming declaration that includes a formal part, or a generic
parameter declaration that includes either a formal part or a
discriminant part.
- A block statement or a loop statement.
In each of the above cases, the declarative region is said to be associated
with the corresponding declaration or statement. A declaration is said to
occur immediately within a declarative region if this region is the
innermost region that encloses the declaration, not counting the
declarative region (if any) associated with the declaration itself.
A declaration that occurs immediately within a declarative region is said
to be local to the region. Declarations in outer (enclosing) regions are
said to be global to an inner (enclosed) declarative region. A local
entity is one declared by a local declaration; a global entity is one
declared by a global declaration.
8 - 1
Some of the above forms of declarative region include several disjoint
parts (for example, other declarative items can be between the declaration
of a package and its body). Each declarative region is nevertheless
considered as a (logically) continuous portion of the program text. Hence
if any rule defines a portion of text as the text that extends from some
specific point of a declarative region to the end of this region, then this
portion is the corresponding subset of the declarative region (for example
it does not include intermediate declarative items between the two parts of
a package).
8 - 2
Notes:
As defined in section 3.1, the term declaration includes basic
declarations, implicit declarations, and those declarations that are part
of basic declarations, for example, discriminant and parameter
specifications. It follows from the definition of a declarative region
that a discriminant specification occurs immediately within the region
associated with the enclosing record type declaration. Similarly, a
parameter specification occurs immediately within the region associated
with the enclosing subprogram body or accept statement.
The package STANDARD forms a declarative region which encloses all library
units: the implicit declaration of each library unit is assumed to occur
immediately within this package (see sections 8.6 and 10.1.1).
Declarative regions can be nested within other declarative regions. For
example, subprograms, packages, task units, generic units, and block
statements can be nested within each other, and can contain record type
declarations, loop statements, and accept statements.
References: accept statement 9.5, basic declaration 3.1, block statement
5.6, body stub 10.2, declaration 3.1, discriminant part 3.7.1, discriminant
specification 3.7.1, entry declaration 9.5, formal part 6.1, generic body
12.2, generic declaration 12.1, generic parameter declaration 12.1,
implicit declaration 3.1, incomplete type declaration 3.8.1, library unit
10.1, loop statement 5.5, package 7, package body 7.1, package declaration
7.1, parameter specification 6.1, private type declaration 7.4, record
representation clause 13.4, record type 3.7, renaming declaration 8.5,
standard package 8.6, subprogram body 6.3, subprogram declaration 6.1,
subunit 10.2, task body 9.1, task declaration 9.1, task unit 9
8.2 Scope of Declarations
For each form of 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 entity declared by the
declaration. Furthermore, if the declaration associates some notation with
a declared entity, this portion of the text is also called the scope of
this notation (either an identifier, a character literal, an operator
symbol, or the notation for a basic operation). Within the scope of an
entity, and only there, there are places where it is legal to use the
associated notation in order to refer to the declared entity. These places
are defined by the rules of visibility and overloading.
The scope of a declaration that occurs immediately within a declarative
region extends from the beginning of the declaration to the end of the
declarative region; this part of the scope of a declaration is called the
immediate scope. Furthermore, for any of the declarations listed below,
the scope of the declaration extends beyond the immediate scope:
8 - 3
(a) A declaration that occurs immediately within the visible part of a
package declaration.
(b) An entry declaration.
(c) A component declaration.
(d) A discriminant specification.
(e) A parameter specification.
(f) A generic parameter declaration.
8 - 4
In each of these cases, the given declaration occurs immediately within
some enclosing declaration, and the scope of the given declaration extends
to the end of the scope of the enclosing declaration.
In the absence of a subprogram declaration, the subprogram specification
given in the subprogram body or in the body stub acts as the declaration
and rule (e) applies also in such a case.
Note:
The above scope rules apply to all forms of declaration defined by section
3.1; in particular, they apply also to implicit declarations. Rule (a)
applies to a package declaration and thus not to the package specification
of a generic declaration. For nested declarations, the rules (a) through
(f) apply at each level. For example, if a task unit is declared in the
visible part of a package, the scope of an entry of the task unit extends
to the end of the scope of the task unit, that is, to the end of the scope
of the enclosing package. The scope of a use clause is defined in section
8.4.
References: basic operation 3.3.3, body stub 10.2, character literal 2.5,
component declaration 3.7, declaration 3.1, declarative region 8.1,
discriminant specification 3.7.1, entry declaration 9.5, extends 8.1,
generic declaration 12.1, generic parameter declaration 12.1, identifier
2.3, implicit declaration 3.1, occur immediately within 8.1, operator
symbol 6.1, overloading 6.6 8.7, package declaration 7.1, package
specification 7.1, parameter specification 6.1, record type 3.7, renaming
declaration 8.5, subprogram body 6.3, subprogram declaration 6.1, task
declaration 9.1, task unit 9, type declaration 3.3.1, use clause 8.4,
visibility 8.3, visible part 7.2
8.3 Visibility
The meaning of the occurrence of an identifier at a given place in the text
is defined by the visibility rules and also, in the case of overloaded
declarations, by the overloading rules. The identifiers considered in this
chapter include any identifier other than a reserved word, an attribute
designator, a pragma identifier, the identifier of a pragma argument, or an
identifier given as a pragma argument. The places considered in this
chapter are those where a lexical element (such as an identifier) occurs.
The overloaded declarations considered in this chapter are those for
subprograms, enumeration literals, and single entries.
For each identifier and at each place in the text, the visibility rules
determine a set of declarations (with this identifier) that define possible
meanings of an occurrence of the identifier. A declaration is said to be
visible at a given place in the text when, according to the visibility
rules, the declaration defines a possible meaning of this occurrence. Two
cases arise.
8 - 5
- The visibility rules determine at most one possible meaning. In such
a case the visibility rules are sufficient to determine the
declaration defining the meaning of the occurrence of the identifier,
or in the absence of such a declaration, to determine that the
occurrence is not legal at the given point.
- The visibility rules determine more than one possible meaning. In
such a case the occurrence of the identifier is legal at this point if
and only if exactly one visible declaration is acceptable for the
overloading rules in the given context (see section 6.6 for the rules
of overloading and section 8.7 for the context used for overload
resolution).
8 - 6
A declaration is only visible within a certain part of its scope; this
part starts at the end of the declaration except in a package
specification, in which case it starts at the reserved word is given after
the identifier of the package specification. (This rule applies, in
particular, for implicit declarations.)
Visibility is either by selection or direct. A declaration is visible by
selection at places that are defined as follows.
(a) For a declaration given in the visible part of a package declaration:
at the place of the selector after the dot of an expanded name whose
prefix denotes the package.
(b) For an entry declaration of a given task type: at the place of the
selector after the dot of a selected component whose prefix is
appropriate for the task type.
(c) For a component declaration of a given record type declaration: at
the place of the selector after the dot of a selected component whose
prefix is appropriate for the type; also at the place of a component
simple name (before the compound delimiter =>) in a named component
association of an aggregate of the type.
(d) For a discriminant specification of a given type declaration: at the
same places as for a component declaration; also at the place of a
discriminant simple name (before the compound delimiter =>) in a named
discriminant association of a discriminant constraint for the type.
(e) For a parameter specification of a given subprogram specification or
entry declaration: at the place of the formal parameter (before the
compound delimiter =>) in a named parameter association of a
corresponding subprogram or entry call.
(f) For a generic parameter declaration of a given generic unit: at the
place of the generic formal parameter (before the compound delimiter
=>) in a named generic association of a corresponding generic
instantiation.
Finally, within the declarative region associated with a construct other
than a record type declaration, any declaration that occurs immediately
within the region is visible by selection at the place of the selector
after the dot of an expanded name whose prefix denotes the construct.
Where it is not visible by selection, a visible declaration is said to be
directly visible. A declaration is directly visible within a certain part
of its immediate scope; this part extends to the end of the immediate
scope of the declaration, but excludes places where the declaration is
hidden as explained below. In addition, a declaration occurring
immediately within the visible part of a package can be made directly
visible by means of a use clause according to the rules described in
section 8.4. (See also section 8.6 for the visibility of library units.)
A declaration is said to be hidden within (part of) an inner declarative
region if the inner region contains a homograph of this declaration; the
outer declaration is then hidden within the immediate scope of the inner
8 - 7
homograph. Each of two declarations is said to be a homograph of the other
if both declarations have the same identifier and overloading is allowed
for at most one of the two. If overloading is allowed for both
declarations, then each of the two is a homograph of the other if they have
the same identifier, operator symbol, or character literal, as well as the
same parameter and result type profile (see 6.6).
Within the specification of a subprogram, every declaration with the same
designator as the subprogram is hidden; the same holds within a generic
instantiation that declares a subprogram, and within an entry declaration
or the formal part of an accept statement; where hidden in this manner, a
declaration is visible neither by selection nor directly.
8 - 8
Two declarations that occur immediately within the same declarative region
must not be homographs, unless either or both of the following requirements
are met: (a) exactly one of them is the implicit declaration of a
predefined operation; (b) exactly one of them is the implicit declaration
of a derived subprogram. In such cases, a predefined operation is always
hidden by the other homograph; a derived subprogram hides a predefined
operation, but is hidden by any other homograph. Where hidden in this
manner, an implicit declaration is hidden within the entire scope of the
other declaration (regardless of which declaration occurs first); the
implicit declaration is visible neither by selection nor directly.
Whenever a declaration with a certain identifier is visible from a given
point, the identifier and the declared entity (if any) are also said to be
visible from that point. Direct visibility and visibility by selection are
likewise defined for character literals and operator symbols. An operator
is directly visible if and only if the corresponding operator declaration
is directly visible. Finally, the notation associated with a basic
operation is directly visible within the entire scope of this operation.
Example:
procedure P is
A, B : BOOLEAN;
procedure Q is
C : BOOLEAN;
B : BOOLEAN; -- an inner homograph of B
begin
...
B := A; -- means Q.B := P.A;
C := P.B; -- means Q.C := P.B;
end;
begin
...
A := B; -- means P.A := P.B;
end;
Note on the visibility of library units:
The visibility of library units is determined by with clauses (see 10.1.1)
and by the fact that library units are implicitly declared in the package
STANDARD (see 8.6).
Note on homographs:
The same identifier may occur in different declarations and may thus be
associated with different entities, even if the scopes of these
declarations overlap. Overlap of the scopes of declarations with the same
identifier can result from overloading of subprograms and of enumeration
literals. Such overlaps can also occur for entities declared in package
visible parts and for entries, record components, and parameters, where
there is overlap of the scopes of the enclosing package declarations, task
declarations, record type declarations, subprogram declarations, renaming
declarations, or generic declarations. Finally overlapping scopes can
result from nesting.
8 - 9
Note on immediate scope, hiding, and visibility:
The rules defining immediate scope, hiding, and visibility imply that a
reference to an identifier within its own declaration is illegal (except
for packages and generic packages). The identifier hides outer homographs
within its immediate scope, that is, from the start of the declaration;
on the other hand, the identifier is visible only after the end of the
declaration. For this reason, all but the last of the following
declarations are illegal:
8 - 10
K : INTEGER := K * K; -- illegal
T : T; -- illegal
procedure P(X : P); -- illegal
procedure Q(X : REAL := Q); -- illegal, even if there is a function named Q
procedure R(R : REAL); -- an inner declaration is legal (although confusing)
References: accept statement 9.5, aggregate 4.3, appropriate for a type
4.1, argument 2.8, basic operation 3.3.3, character literal 2.5, component
association 4.3, component declaration 3.7, compound delimiter 2.2,
declaration 3.1, declarative region 8.1, designate 3.8, discriminant
constraint 3.7.2, discriminant specification 3.7.1, entry call 9.5, entry
declaration 9.5, entry family 9.5, enumeration literal specification 3.5.1,
expanded name 4.1.3, extends 8.1, formal parameter 6.1, generic association
12.3, generic formal parameter 12.1, generic instantiation 12.3, generic
package 12.1, generic parameter declaration 12.1, generic unit 12,
identifier 2.3, immediate scope 8.2, implicit declaration 3.1, lexical
element 2.2, library unit 10.1, object 3.2, occur immediately within 8.1,
operator 4.5, operator symbol 6.1, overloading 6.6 8.7, package 7,
parameter 6.2, parameter association 6.4, parameter specification 6.1,
pragma 2.8, program unit 6, record type 3.7, reserved word 2.9, scope 8.2,
selected component 4.1.3, selector 4.1.3, simple name 4.1, subprogram 6,
subprogram call 6.4, subprogram declaration 6.1, subprogram specification
6.1, task type 9.1, task unit 9, type 3.3, type declaration 3.3.1, use
clause 8.4, visible part 7.2
8.4 Use Clauses
A use clause achieves direct visibility of declarations that appear in the
visible parts of named packages.
use_clause ::= use package_name {, package_name};
For each use clause, there is a certain region of text called the scope of
the use clause. This region starts immediately after the use clause. If a
use clause is a declarative item of some declarative region, the scope of
the clause extends to the end of the declarative region. If a use clause
occurs within a context clause of a compilation unit, the scope of the use
clause extends to the end of the declarative region associated with the
compilation unit.
In order to define which declarations are made directly visible at a given
place by use clauses, consider the set of packages named by all use clauses
whose scopes enclose this place, omitting from this set any packages that
enclose this place. A declaration that can be made directly visible by a
use clause (a potentially visible declaration) is any declaration that
occurs immediately within the visible part of a package of the set. A
potentially visible declaration is actually made directly visible except in
the following two cases:
- A potentially visible declaration is not made directly visible if the
place considered is within the immediate scope of a homograph of the
8 - 11
declaration.
- Potentially visible declarations that have the same identifier are not
made directly visible unless each of them is either an enumeration
literal specification or the declaration of a subprogram (by a
subprogram declaration, a renaming declaration, a generic
instantiation, or an implicit declaration).
The elaboration of a use clause has no other effect.
Note:
The above rules guarantee that a declaration that is made directly visible
by a use clause cannot hide an otherwise directly visible declaration. The
above rules are formulated in terms of the set of packages named by use
clauses.
8 - 12
Consequently, the following lines of text all have the same effect
(assuming only one package P).
use P;
use P; use P, P;
Example of conflicting names in two packages:
procedure R is
package TRAFFIC is
type COLOR is (RED, AMBER, GREEN);
...
end TRAFFIC;
package WATER_COLORS is
type COLOR is (WHITE, RED, YELLOW, GREEN, BLUE, BROWN, BLACK);
...
end WATER_COLORS;
use TRAFFIC; -- COLOR, RED, AMBER, and GREEN are directly visible
use WATER_COLORS; -- two homographs of GREEN are directly visible
-- but COLOR is no longer directly visible
subtype LIGHT is TRAFFIC.COLOR; -- Subtypes are used to resolve
subtype SHADE is WATER_COLORS.COLOR; -- the conflicting type name COLOR
SIGNAL : LIGHT;
PAINT : SHADE;
begin
SIGNAL := GREEN; -- that of TRAFFIC
PAINT := GREEN; -- that of WATER_COLORS
end R;
Example of name identification with a use clause:
package D is
T, U, V : BOOLEAN;
end D;
procedure P is
package E is
B, W, V : INTEGER;
end E;
procedure Q is
T, X : REAL;
use D, E;
begin
-- the name T means Q.T, not D.T
-- the name U means D.U
-- the name B means E.B
-- the name W means E.W
-- the name X means Q.X
-- the name V is illegal : either D.V or E.V must be used
...
8 - 13
end Q;
begin
...
end P;
8 - 14
References: compilation unit 10.1, context clause 10.1, declaration 3.1,
declarative item 3.9, declarative region 8.1, direct visibility 8.3,
elaboration 3.1 3.9, elaboration has no other effect 3.1, enumeration
literal specification 3.5.1, extends 8.1, hiding 8.3, homograph 8.3,
identifier 2.3, immediate scope 8.2, name 4.1, occur immediately within
8.1, package 7, scope 8.2, subprogram declaration 6.1, visible part 7.2
8.5 Renaming Declarations
A renaming declaration declares another name for an entity.
renaming_declaration ::=
identifier : type_mark renames object_name;
| identifier : exception renames exception_name;
| package identifier renames package_name;
| subprogram_specification renames subprogram_or_entry_name;
The elaboration of a renaming declaration evaluates the name that follows
the reserved word renames and thereby determines the entity denoted by this
name (the renamed entity). At any point where a renaming declaration is
visible, the identifier, or operator symbol of this declaration denotes the
renamed entity.
The first form of renaming declaration is used for the renaming of objects.
The renamed entity must be an object of the base type of the type mark.
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 type mark of the
renaming declaration is ignored). The renaming declaration is legal only
if exactly one object has this type and can be denoted by the object name.
The following restrictions apply to the renaming of a subcomponent that
depends on discriminants of a variable. The renaming is not allowed if the
subtype of the variable, as defined in a corresponding object declaration,
component declaration, or component subtype indication, is an unconstrained
type; or if the variable is a generic formal object (of mode in out).
Similarly if the variable is a formal parameter, the renaming is not
allowed if the type mark given in the parameter specification denotes an
unconstrained type whose discriminants have default expressions.
The second form of renaming declaration is used for the renaming of
exceptions; the third form, for the renaming of packages.
The last form of renaming declaration is used for the renaming of
subprograms and entries. The renamed subprogram or entry and the
subprogram specification given in the renaming declaration must have the
same parameter and result type profile (see 6.6). The renaming declaration
is legal only if exactly one visible subprogram or entry satisfies the
above requirements and can be denoted by the given subprogram or entry
name. In addition, parameter modes must be identical for formal parameters
8 - 15
that are at the same parameter position.
The subtypes of the parameters and result (if any) of a renamed subprogram
or entry are not affected by renaming. These subtypes are those given in
the original subprogram declaration, generic instantiation, or entry
declaration (not those of the renaming declaration); even for calls that
use the new name. On the other hand, a renaming declaration can introduce
parameter names and default expressions that differ from those of the
renamed subprogram; named associations of calls with the new subprogram
name must use the new parameter name; calls with the old subprogram name
must use the old parameter names.
8 - 16
A procedure can only be renamed as a procedure. Either of a function or
operator can be renamed as either of a function or operator; for renaming
as an operator, the subprogram specification given in the renaming
declaration is subject to the rules given in section 6.7 for operator
declarations. Enumeration literals can be renamed as functions;
similarly, attributes defined as functions (such as 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.
Examples:
declare
L : PERSON renames LEFTMOST_PERSON; -- see 3.8.1
begin
L.AGE := L.AGE + 1;
end;
FULL : exception renames TABLE_MANAGER.TABLE_FULL; -- see 7.5
package TM renames TABLE_MANAGER;
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 3.5.1
function ROT return COLOR renames RED;
function ROSSO return COLOR renames ROUGE;
function NEXT(X : COLOR) return COLOR renames COLOR'SUCC; -- see 3.5.5
Example of a renaming declaration with new parameter names:
function "*" (X,Y : VECTOR) return REAL renames DOT_PRODUCT; -- see 6.1
Example of a renaming declaration with a new default expression:
function MINIMUM(L : LINK := HEAD) return CELL renames MIN_CELL; -- see 6.1
Notes:
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
points. The attributes POS and VAL cannot be renamed since the
corresponding specifications cannot be written; the same holds for the
predefined multiplying operators with a universal_fixed result.
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; similarly, the COUNT
attribute is not available for the new name.
8 - 17
A task object that is declared by an object declaration can be renamed as
an object. However, a single task cannot be renamed since the
corresponding task type is anonymous. For similar reasons, an object of an
anonymous array type cannot be renamed. No syntactic form exists for
renaming a generic unit.
A subtype can be used to achieve the effect of renaming a type (including a
task type) as in
subtype MODE is TEXT_IO.FILE_MODE;
8 - 18
References: allow 1.6, attribute 4.1.4, base type 3.3, conditional entry
call 9.7.2, constant 3.2.1, constrained subtype 3.3, constraint 3.3,
declaration 3.1, default expression 6.1, depend on a discriminant 3.7.1,
discriminant 3.7.1, elaboration 3.1 3.9, entry 9.5, entry call 9.5, entry
call statement 9.5, entry declaration 9.5, entry family 9.5, enumeration
literal 3.5.1, evaluation of a name 4.1, exception 11, formal parameter
6.1, function 6.5, identifier 2.3, legal 1.6, mode 6.1, name 4.1, object
3.2, object declaration 3.2, operator 6.7, operator declaration 6.7,
operator symbol 6.1, package 7, parameter 6.2, parameter specification 6.1,
procedure 6.1, procedure call statement 6.4, reserved word 2.9,
subcomponent 3.3, subprogram 6, subprogram call 6.4, subprogram declaration
6.1, subprogram specification 6.1, subtype 3.3.2, task object 9.2, timed
entry call 9.7.3, type 3.3, type mark 3.3.2, variable 3.2.1, visibility 8.3
8.6 The Package Standard
The predefined types (for example the types BOOLEAN, CHARACTER and INTEGER)
are the types that are declared in a predefined package called STANDARD;
this package also includes the declarations of their predefined operations.
The package STANDARD is described in Annex C. Apart from the predefined
numeric types, the specification of the package STANDARD must be the same
for all implementations of the language.
The package STANDARD forms a declarative region which encloses every
library unit and consequently the main program; the declaration of every
library unit is assumed to occur immediately within this package. The
implicit declarations of library units are assumed to be ordered in such a
way that the scope of a given library unit includes any compilation unit
that mentions the given library unit in a with clause. However, the only
library units that are visible within a given compilation unit are as
follows: they include the library units named by all with clauses that
apply to the given unit, and moreover, if the given unit is a secondary
unit of some library unit, they include this library unit.
Notes:
If all block statements of a program are named, then the name of each
program unit can always be written as an expanded name starting with
STANDARD (unless this package is itself hidden).
If a type is declared in the visible part of a library package, then it is
a consequence of the visibility rules that a basic operation (such as
assignment) for this type is directly visible at places where the type
itself is not visible (whether by selection or directly). However this
operation can only be applied to operands that are visible and the
declaration of these operands requires the visibility of either the type or
one of its subtypes.
References: applicable with clause 10.1.1, block name 5.6, block statement
5.6, declaration 3.1, declarative region 8.1, expanded name 4.1.3, hiding
8 - 19
8.3, identifier 2.3, implicit declaration 3.1, library unit 10.1, loop
statement 5.5, main program 10.1, must 1.6, name 4.1, occur immediately
within 8.1, operator 6.7, package 7, program unit 6, secondary unit 10.1,
subtype 3.3, type 3.3, visibility 8.3, with clause 10.1.1
8.7 The Context of Overload Resolution
Overloading is defined for subprograms, enumeration literals, operators,
and single entries, and also for the operations that are inherent in
several basic operations such as assignment, membership tests, allocators,
the literal null, aggregates, and string literals.
8 - 20
For overloaded entities, overload resolution determines the actual meaning
that an occurrence of an identifier has, whenever the visibility rules have
determined that more than one meaning is acceptable at the place of this
occurrence; overload resolution likewise determines the actual meaning of
an occurrence of an operator or some basic operation.
At such a place all visible declarations are considered. The occurrence is
only legal if there is exactly one interpretation of each constituent of
the innermost complete context; a complete context is one of the
following:
- A declaration.
- A statement.
- A representation clause.
When considering possible interpretations of a complete context, the only
rules considered are the syntax rules, the scope and visibility rules, and
the rules of the form described below.
(a) Any rule that requires a name or expression to have a certain type, or
to have the same type as another name or expression.
(b) Any rule that requires the type of a name or expression to be a type
of a certain class; similarly, any rule that requires a certain type
to be a discrete, integer, real, universal, character, boolean, or
nonlimited type.
(c) Any rule that requires a prefix to be appropriate for a certain type.
(d) Any rule that specifies a certain type as the result type of a basic
operation, and any rule that specifies that this type is of a certain
class.
(e) The rules that require the type of an aggregate or string literal to
be determinable solely from the enclosing complete context (see 4.3
and 4.2). Similarly, the rules that require the type of the prefix of
an attribute, the type of the expression of a case statement, or the
type of the operand of a type conversion, to be determinable
independently of the context (see 4.1.4, 5.4, 4.6, and 6.4.1).
(f) The rules given in section 6.6, for the resolution of overloaded
subprogram calls; in section 4.6, for the implicit conversions of
universal expressions; in section 3.6.1, for the interpretation of
discrete ranges with bounds having a universal type; and in section
4.1.3, for the interpretation of an expanded name whose prefix denotes
a subprogram or an accept statement.
Subprogram names used as pragma arguments follow a different rule: the
pragma can apply to several overloaded subprograms, as explained in section
6.3.2 for the pragma INLINE, in section 11.7 for the pragma SUPPRESS, and
in section 13.9 for the pragma INTERFACE.
8 - 21
Similarly, the simple names given in context clauses (see 10.1.1) and in
address clauses (see 13.5) follow different rules.
8 - 22
Notes:
If there is only one possible interpretation, the identifier denotes the
corresponding entity. However, this does not mean that the occurrence is
necessarily legal since other requirements exist which are not considered
for overload resolution; for example, the fact that an expression is
static, the parameter modes, whether an object is constant, conformance
rules, forcing occurrences for a representation clause, 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).
Rules that require certain constructs to have the same parameter and result
type profile fall under the category (a); the same holds for rules that
require conformance of two constructs since conformance requires that
corresponding names be given the same meaning by the visibility and
overloading rules.
A loop parameter specification is a declaration, and hence a complete
context.
References: aggregate 4.3, allocator 4.8, assignment 5.2, basic operation
3.3.3, case statement 5.4, class of type 3.3, declaration 3.1, entry 9.5,
enumeration literal 3.5.1, exception 11, expression 4.4, formal part 6.1,
identifier 2.3, legal 1.6, literal 4.2, loop parameter specification 5.5,
membership test 4.5.2, name 4.1, null literal 3.8, operation 3.3.3,
operator 4.5, overloading 6.6, pragma 2.8, representation clause 13.1,
statement 5, static expression 4.9, static subtype 4.9, subprogram 6,
subtype 3.3, type conversion 4.6, visibility 8.3
Rules of the form (a): address clause 13.5, assignment 5.2, choice 3.7.3
4.3.2 5.4, component association 4.3.1 4.3.2, conformance rules 9.5,
default expression 3.7 3.7.1 6.1 12.1.1, delay statement 9.6, discrete
range 3.6.1 5.5 9.5, discriminant constraint 3.7.2, enumeration
representation clause 13.3, generic parameter association 12.3.1, index
constraint 3.6.1, index expression 4.1.1 4.1.2 9.5, initial value 3.2.1,
membership test 4.5.2, parameter association 6.4.1, parameter and result
type profile 8.5 12.3.6, qualified expression 4.7, range constraint 3.5,
renaming of an object 8.5, result expression 5.8
Rules of the form (b): abort statement 9.10, assignment 5.2, case
expression 5.4, condition 5.3 5.5 5.7 9.7.1, discrete range 3.6.1 5.5 9.5,
fixed point type declaration 3.5.9, floating point type declaration 3.5.7,
integer type declaration 3.5.4, length clause 13.2, membership test 4.4,
number declaration 3.2.2, record representation clause 13.4, selected
component 4.1.3, short-circuit control form 4.4, val attribute 3.5.5
Rules of the form (c): indexed component 4.1.1, selected component 4.1.3,
slice 4.1.2
Rules of the form (d): aggregate 4.3, allocator 4.8, membership test 4.4,
null literal 4.2, numeric literal 2.4, short-circuit control form 4.4,
string literal 4.2
8 - 23