8 Visibility Rules
1/3 {AI05-0299-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 clause. The formulation of these rules uses the notion of a
declarative region.
2/3 {AI05-0299-1} As explained in Clause 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.]
2.a To be honest: In some cases, a usage name that denotes a
declaration does not denote the view declared by that declaration,
nor the entity of that view, but instead denotes a view of the
current instance of the entity, and denotes the current instance
of the entity. This sometimes happens when the usage name occurs
inside the declarative region of the declaration.
Wording Changes from Ada 83
2.b We no longer define the term "basic operation;" thus we no longer
have to worry about the visibility of them. Since they were
essentially always visible in Ada 83, this change has no effect.
The reason for this change is that the definition in Ada 83 was
confusing, and not quite correct, and we found it difficult to
fix. For example, one wonders why an if_statement was not a basic
operation of type Boolean. For another example, one wonders what
it meant for a basic operation to be "inherent in" something.
Finally, this fixes the problem addressed by AI83-00027/07.
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];
2.1/4 * {AI12-0094-1} an access_definition;
3 * a block_statement;
4 * a loop_statement;
4.1/3 * {AI05-0255-1} a quantified_expression;
4.2/3 * {AI95-00318-02} 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.
11.a Reason: This is so that the component_declarations can be directly
visible in the record_representation_clause.
12 The declarative region of a declaration is also called the declarative
region of any view or entity declared by the declaration.
12.a Reason: The constructs that have declarative regions are the
constructs that can have declarations nested inside them. Nested
declarations are declared in that declarative region. The one
exception is for enumeration literals; although they are nested
inside an enumeration type declaration, they behave as if they
were declared at the same level as the type.
12.b To be honest: A declarative region does not include
parent_unit_names.
12.c Ramification: A declarative region does not include
context_clauses.
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.
13.a Discussion: Don't confuse the declarative region of a declaration
with the declarative region in which it immediately occurs.
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.]
14.a Ramification: "Occurs immediately within" and "local to" are
synonyms (when referring to declarations).
14.b Thus, "local to" applies to both declarations and entities,
whereas "occurs immediately within" only applies to declarations.
We use this term only informally; for cases where precision is
required, we use the term "occurs immediately within", since it is
less likely to cause confusion.
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.
18.a Discussion: It is necessary for the things that have a declarative
region to include anything that contains declarations (except for
enumeration type declarations). This includes any declaration that
has a profile (that is, subprogram_declaration, subprogram_body,
entry_declaration, subprogram_renaming_declaration,
formal_subprogram_declaration, access-to-subprogram
type_declaration), anything that has a discriminant_part (that is,
various kinds of type_declaration), anything that has a
component_list (that is, record type_declaration and record
extension type_declaration), and finally the declarations of task
and protected units and packages.
Wording Changes from Ada 83
18.b It was necessary to extend Ada 83's definition of declarative
region to take the following Ada 95 features into account:
18.c * Child library units.
18.d * Derived types/type extensions - we need a declarative region
for inherited components and also for new components.
18.e * All the kinds of types that allow discriminants.
18.f * Protected units.
18.g * Entries that have bodies instead of accept statements.
18.h * The choice_parameter_specification of an exception_handler.
18.i * The formal parameters of access-to-subprogram types.
18.j * Renamings-as-body.
18.k Discriminated and access-to-subprogram type declarations need a
declarative region. Enumeration type declarations cannot have one,
because you don't have to say "Color.Red" to refer to the literal
Red of Color. For other type declarations, it doesn't really
matter whether or not there is an associated declarative region,
so for simplicity, we give one to all types except enumeration
types.
18.l We now say that an accept_statement has its own declarative
region, rather than being part of the declarative region of the
entry_declaration, so that declarative regions are properly nested
regions of text, so that it makes sense to talk about "inner
declarative regions," and "...extends to the end of a declarative
region." Inside an accept_statement, the name of one of the
parameters denotes the parameter_specification of the
accept_statement, not that of the entry_declaration. If the
accept_statement is nested within a block_statement, these
parameter_specifications can hide declarations of the
block_statement. The semantics of such cases was unclear in RM83.
18.m To be honest: Unfortunately, we have the same problem for the
entry name itself - it should denote the accept_statement, but
accept_statements are not declarations. They should be, and they
should hide the entry from all visibility within themselves.
18.n Note that we can't generalize this to entry_bodies, or other
bodies, because the declarative_part of a body is not supposed to
contain (explicit) homographs of things in the declaration. It
works for accept_statements only because an accept_statement does
not have a declarative_part.
18.o To avoid confusion, we use the term "local to" only informally in
Ada 95. Even RM83 used the term incorrectly (see, for example,
RM83-12.3(13)).
18.p In Ada 83, (root) library units were inside Standard; it was not
clear whether the declaration or body of Standard was meant. In
Ada 95, they are children of Standard, and so occur immediately
within Standard's declarative region, but not within either the
declaration or the body. (See RM83-8.6(2) and RM83-10.1.1(5).)
Wording Changes from Ada 95
18.q/2 {AI95-00318-02} Extended_return_statement (see 6.5) is added to
the list of constructs that have a declarative region.
Extensions to Ada 2012
18.r/4 {AI12-0094-1} Corrigendum: access_definition is added to the list
of constructs that have a declarative region. This allows
parameter names declared in anonymous access type subprogram types
to be the same as other names declared outside. For instance:
18.s/4 type Foo is record
A : Natural;
B : access procedure (A : Boolean);
end record;
18.t/4 This is now legal, as one would expect; it was illegal in previous
versions of Ada as the parameter A and the component A were
homographs in the same declarative region (see 8.3). Note that
some implementations already allow this common sense
interpretation, so this extension may in fact be used in existing
code.
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:
2.a Reason: The reason for making overloadable declarations with
profiles special is to simplify compilation: until the compiler
has determined the profile, it doesn't know which other
declarations are homographs of this one, so it doesn't know which
ones this one should hide. Without this rule, two passes over the
_specification or generic_instantiation would be required to
resolve names that denote things with the same name as this one.
3 * The immediate scope of a library_item includes only its semantic
dependents.
3.a/3 Reason: {AI05-0299-1} Clause 10 defines only a partial ordering of
library_items. Therefore, it is a good idea to restrict the
immediate scope (and the scope, defined below) to semantic
dependents.
3.b Consider also examples like this:
3.c package P is end P;
3.d package P.Q is
I : Integer := 0;
end P.Q;
3.e/1 with P;
package R is
package X renames P;
J : Integer := X.Q.I; -- Illegal!
end R;
3.f The scope of P.Q does not contain R. Hence, neither P.Q nor X.Q
are visible within R. However, the name R.X.Q would be visible in
some other library unit where both R and P.Q are visible (assuming
R were made legal by removing the offending declaration).
3.g/2 Ramification: {AI95-00217-06} This rule applies to limited views
as well as "normal" library items. In that case, the semantic
dependents are the units that have a limited_with_clause for the
limited view.
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.
4.a Ramification: In other words, a declaration in the private part
can be visible within the visible part, private part and body of a
private child unit. On the other hand, such a declaration can be
visible within only the private part and body of a public child
unit.
4.b Reason: The purpose of this rule is to prevent children from
giving private information to clients.
4.c/2 Ramification: {AI95-00231-01} For a public child subprogram, this
means that the parent's private part is not visible in the profile
of the declaration and of the body. This is true even for
subprogram_bodies that are not completions. For a public child
generic unit, it means that the parent's private part is not
visible in the generic_formal_part, as well as in the first list
of basic_declarative_items (for a generic package), or the
(syntactic) profile (for a generic subprogram).
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.
8.a Reason: Although there is no way to reference anything but the
formals from outside a generic unit, they are still in the visible
part in the sense that the corresponding declarations in an
instance can be referenced (at least in some cases). In other
words, these declarations have an effect on the outside world. The
visible part of a generic unit needs to be defined this way in
order to properly support the rule that makes a parent's private
part invisible within a public child's visible part.
8.b Ramification: The visible part of an instance of a generic unit is
as defined for packages and subprograms; it is not defined in
terms of the visible part of a generic unit.
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.a Ramification: Note the recursion. If a declaration appears in the
visible part of a library unit, its scope extends to the end of
the scope of the library unit, but since that only includes
dependents of the declaration of the library unit, the scope of
the inner declaration also only includes those dependents. If X
renames library package P, which has a child Q, a with_clause
mentioning P.Q is necessary to be able to refer to X.Q, even if
P.Q is visible at the place where X is declared.
10.1/3 {AI95-00408-01} {AI05-0183-1} 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. The scope of an
aspect_specification is identical to the scope of the associated declaration.
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.
11.a Ramification: The rule for immediate scope implies the following:
11.b * If the declaration is that of a library unit, then the
immediate scope includes the declarative region of the
declaration itself, but not other places, unless they are
within the scope of a with_clause that mentions the library
unit.
11.c It is necessary to attach the semantics of with_clauses to
[immediate] scopes (as opposed to visibility), in order for
various rules to work properly. A library unit should hide a
homographic implicit declaration that appears in its parent,
but only within the scope of a with_clause that mentions the
library unit. Otherwise, we would violate the "legality
determinable via semantic dependences" rule of 10, "
Program Structure and Compilation Issues". The declaration of
a library unit should be allowed to be a homograph of an
explicit declaration in its parent's body, so long as that
body does not mention the library unit in a with_clause.
11.d This means that one cannot denote the declaration of the
library unit, but one might still be able to denote the
library unit via another view.
11.e A with_clause does not make the declaration of a library unit
visible; the lack of a with_clause prevents it from being
visible. Even if a library unit is mentioned in a
with_clause, its declaration can still be hidden.
11.f * The completion of the declaration of a library unit (assuming
that's also a declaration) is not visible, neither directly
nor by selection, outside that completion.
11.g * The immediate scope of a declaration immediately within the
body of a library unit does not include any child of that
library unit.
11.h This is needed to prevent children from looking inside their
parent's body. The children are in the declarative region of
the parent, and they might be after the parent's body.
Therefore, the scope of a declaration that occurs immediately
within the body might include some children.
12/4 {AI12-0003-1} The immediate scope of a pragma that is not used as a
configuration pragma is defined to be the region extending from immediately
after the pragma to the end of the declarative region immediately enclosing
the pragma.
NOTES
13/3 4 {AI05-0299-1} 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.
13.a/3 Ramification: {AI95-00114-01} {AI05-0299-1} There are some obscure
cases involving generics in which there is no such notation. See
Clause 12.
Extensions to Ada 83
13.b The fact that the immediate scope of an overloadable declaration
does not include its profile is new to Ada 95. It replaces
RM83-8.3(16), which said that within a subprogram specification
and within the formal part of an entry declaration or accept
statement, all declarations with the same designator as the
subprogram or entry were hidden from all visibility. The
RM83-8.3(16) rule seemed to be overkill, and created both
implementation difficulties and unnecessary semantic complexity.
Wording Changes from Ada 83
13.c We no longer need to talk about the scope of notations,
identifiers, character_literals, and operator_symbols.
13.d/3 {AI05-0299-1} The notion of "visible part" has been extended in
Ada 95. The syntax of task and protected units now allows private
parts, thus requiring us to be able to talk about the visible part
as well. It was necessary to extend the concept to subprograms and
to generic units, in order for the visibility rules related to
child library units to work properly. It was necessary to define
the concept separately for generic formal packages, since their
visible part is slightly different from that of a normal package.
Extending the concept to composite types made the definition of
scope slightly simpler. We define visible part for some things
elsewhere, since it makes a big difference to the user for those
things. For composite types and subprograms, however, the concept
is used only in arcane visibility rules, so we localize it to this
subclause.
13.e In Ada 83, the semantics of with_clauses was described in terms of
visibility. It is now described in terms of [immediate] scope.
13.f We have clarified that the following is illegal (where Q and R are
library units):
13.g package Q is
I : Integer := 0;
end Q;
13.h package R is
package X renames Standard;
X.Q.I := 17; -- Illegal!
end R;
13.i even though Q is declared in the declarative region of Standard,
because R does not mention Q in a with_clause.
Wording Changes from Ada 95
13.j/2 {AI95-00408-01} The scope of an attribute_definition_clause is
defined so that it can be used to define the visibility of such a
clause, so that can be used by the stream attribute availability
rules (see 13.13.2).
Wording Changes from Ada 2005
13.k/3 {AI05-0183-1} The scope of an aspect_specification is defined for
similar reasons that it was defined for
attribute_definition_clauses.
Wording Changes from Ada 2012
13.l/4 {AI12-0003-1} The immediate scope of a pragma is defined as it is
used in other rules in the Standard.
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.]
6.a Ramification: Note that a name can have more than one possible
interpretation even if it denotes a nonoverloadable entity. For
example, if there are two functions F that return records, both
containing a component called C, then the name F.C has two
possible interpretations, even though component declarations are
not overloadable.
7 The declarations of callable entities [(including enumeration literals)]
are overloadable[, meaning that overloading is allowed for them].
7.a Ramification: A generic_declaration is not overloadable within its
own generic_formal_part. This follows from the rules about when a
name denotes a current instance. See AI83-00286. This implies that
within a generic_formal_part, outer declarations with the same
defining name are hidden from direct visibility. It also implies
that if a generic formal parameter has the same defining name as
the generic itself, the formal parameter hides the generic from
direct visibility.
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.]
8.a/2 Glossary entry: An overriding operation is one that replaces an
inherited primitive operation. Operations may be marked explicitly
as overriding or not overriding.
9/1 {8652/0025} {AI95-00044-01} [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 * {8652/0025} {AI95-00044-01} A declaration that is not overridable
overrides one that is overridable, [regardless of which declaration
occurs first];
10.a/1 Ramification: {8652/0025} {AI95-00044-01} And regardless of
whether the nonoverridable declaration is overloadable or not. For
example, statement_identifiers are covered by this rule.
10.b The "regardless of which declaration occurs first" is there
because the explicit declaration could be a primitive subprogram
of a partial view, and then the full view might inherit a
homograph. We are saying that the explicit one wins (within its
scope), even though the implicit one comes later.
10.c If the overriding declaration is also a subprogram, then it is a
primitive subprogram.
10.d As explained in 7.3.1, "Private Operations", some inherited
primitive subprograms are never declared. Such subprograms cannot
be overridden, although they can be reached by dispatching calls
in the case of a tagged type.
11 * The implicit declaration of an inherited operator overrides that of a
predefined operator;
11.a Ramification: In a previous version of Ada 9X, we tried to avoid
the notion of predefined operators, and say that they were
inherited from some magical root type. However, this seemed like
too much mechanism. Therefore, a type can have a predefined "+" as
well as an inherited "+". The above rule says the inherited one
wins.
11.b/2 {AI95-00114-01} The "regardless of which declaration occurs
first" applies here as well, in the case where
derived_type_definition in the visible part of a public library
unit derives from a private type declared in the parent unit, and
the full view of the parent type has additional predefined
operators, as explained in 7.3.1, "Private Operations". Those
predefined operators can be overridden by inherited subprograms
implicitly declared earlier.
12 * An implicit declaration of an inherited subprogram overrides a
previous implicit declaration of an inherited subprogram.
12.1/2 * {AI95-00251-01} If two or more homographs are implicitly declared
at the same place:
12.2/2 * {AI95-00251-01} 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 * {AI95-00251-01} 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.
12.a/2 Discussion: In the case where the implementation arbitrarily
chooses one overrider from among a group of inherited subprograms,
users should not be able to determine which member was chosen, as
the set of inherited subprograms which are chosen from must be
fully conformant. This rule is needed in order to allow
12.b/2 package Outer is
package P1 is
type Ifc1 is interface;
procedure Null_Procedure (X : Ifc1) is null;
procedure Abstract_Subp (X : Ifc1) is abstract;
end P1;
12.c/2 package P2 is
type Ifc2 is interface;
procedure Null_Procedure (X : Ifc2) is null;
procedure Abstract_Subp (X : Ifc2) is abstract;
end P2;
12.d/2 type T is abstract new P1.Ifc1 and P2.Ifc2 with null record;
end Outer;
12.e/2 without requiring that T explicitly override any of its inherited
operations.
12.f/2 Full conformance is required here, as we cannot allow the
parameter names to differ. If they did differ, the routine which
was selected for overriding could be determined by using named
parameter notation in a call.
12.g/2 When the subprograms do not conform, we chose not to adopt the "
use clause" rule which would make them all visible resulting in
likely ambiguity. If we had used such a rule, any successful calls
would be confusing; and the fact that there are no Beaujolais-like
effect to worry about means we can consider other rules. The
hidden-from-all-visibility homographs are still inherited by
further derivations, which avoids order-of-declaration
dependencies and other anomalies.
12.h/2 We have to be careful to not include arbitrary selection if the
routines have real bodies. (This can happen in generics, see the
example in the incompatibilities section below.) We don't want the
ability to successfully call routines where the body executed
depends on the compiler or a phase of the moon.
12.i/2 Note that if the type is concrete, abstract subprograms are
inherited as subprograms that require overriding. We include
functions that require overriding as well; these don't have real
bodies, so they can use the more liberal rules.
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.]
13.a Discussion: In addition, this is also stated redundantly (again),
and is repeated, in 12.3, "Generic Instantiation". The rationale
for the rule is explained there.
13.b/3 To be honest: {AI05-0042-1} The implicit subprograms declared when
an operation of a progenitor is implemented by an entry or
subprogram also override the appropriate implicitly declared
inherited operations of the progenitor.
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.
15.a Ramification: We have to talk about the scope of the overriding
declaration, not its visibility, because it hides even when it is
itself hidden.
15.b Note that the scope of an explicit subprogram_declaration does not
start until after its profile.
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/3 * {AI95-00345-01} {AI05-0177-1} For a package_declaration, generic_-
package_declaration, subprogram_body, or expression_function_-
declaration, the declaration is hidden from all visibility only
until the reserved word is of the declaration;
18.a Ramification: We're talking about the is of the construct itself,
here, not some random is that might appear in a
generic_formal_part.
18.1/2 * {AI95-00345-01} 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.
18.b/2 To be honest: If there is neither a with nor is, then the
exception does not apply and the name is hidden from all
visibility until the end of the declaration. This oddity was
inherited from Ada 95.
18.c/2 Reason: We need the "with or is" rule so that the visibility
within an interface_list does not vary by construct. That would
make it harder to complete private extensions and would complicate
implementations.
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.
19.a Ramification: This rule means, for example, that within the scope
of a full_type_declaration that completes a
private_type_declaration, the name of the type will denote the
full_type_declaration, and therefore the full view of the type. On
the other hand, if the completion is not a declaration, then it
doesn't hide anything, and you can't denote it.
20/2 * {AI95-00217-06} {AI95-00412-01} 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.a/2 Discussion: {AI95-00217-06} This is the rule that prevents
with_clauses from being transitive; the [immediate] scope includes
indirect semantic dependents. This rule also prevents the limited
view of a package from being visible in the same place as the full
view of the package, which prevents various ripple effects.
20.1/2 * {AI95-00217-06} {AI95-00412-01} [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/3 {AI95-00195-01} {AI95-00408-01} {AI05-0183-1} An
attribute_definition_clause or an aspect_specification 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.
24.a Discussion: "The same as" has the obvious meaning here, so for +,
the possible interpretations are declarations whose defining name
is "+" (an operator_symbol).
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".
25.a Ramification: Direct visibility is irrelevant for
character_literals. In terms of overload resolution
character_literals are similar to other literals, like null - see
4.2. For character_literals, there is no need to worry about
hiding, since there is no way to declare homographs.
Legality Rules
26/2 {8652/0025} {8652/0026} {AI95-00044-01} {AI95-00150-01} {AI95-00377-01} A
nonoverridable 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 nonoverridable
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].
26.a Discussion: Normally, these rules just mean you can't explicitly
declare two homographs immediately within the same declarative
region. The wording is designed to handle the following special
cases:
26.b * If the second declaration completes the first one, the second
declaration is legal.
26.c * If the body of a library unit contains an explicit homograph
of a child of that same library unit, this is illegal only if
the body mentions the child in its context_clause, or if some
subunit mentions the child. Here's an example:
26.d package P is
end P;
26.e package P.Q is
end P.Q;
26.f package body P is
Q : Integer; -- OK; we cannot see package P.Q here.
procedure Sub is separate;
end P;
26.g with P.Q;
separate(P)
procedure Sub is -- Illegal.
begin
null;
end Sub;
26.h If package body P said "with P.Q;", then it would be illegal
to declare the homograph Q: Integer. But it does not, so the
body of P is OK. However, the subunit would be able to see
both P.Q's, and is therefore illegal.
26.i A previous version of Ada 9X allowed the subunit, and said
that references to P.Q would tend to be ambiguous. However,
that was a bad idea, because it requires overload resolution
to resolve references to directly visible nonoverloadable
homographs, which is something compilers have never before
been required to do.
26.i.1/1 * {8652/0026} {8652/0102} {AI95-00150-01} {AI95-00157-01} If a
type extension contains a component with the same name as a
component in an ancestor type, there must be no place where
both components are visible. For instance:
26.i.2/1 package A is
type T is tagged private;
package B is
type NT is new T with record
I: Integer; -- Illegal because T.I is visible in the body.
end record; -- T.I is not visible here.
end B;
private
type T is tagged record
I: Integer; -- Illegal because T.I is visible in the body.
end record;
end A;
26.i.3/2 {AI95-00114-01} package body A is
package body B is
-- T.I becomes visible here.
end B;
end A;
26.i.4/1 package A.C is
type NT2 is new A.T with record
I: Integer; -- Illegal because T.I is visible in the private part.
end record; -- T.I is not visible here.
private
-- T.I is visible here.
end A.C;
26.i.5/1 with A;
package D is
type NT3 is new A.T with record
I: Integer; -- Legal because T.I is never visible in this package.
end record;
end D;
26.i.6/1 with D;
package A.E is
type NT4 is new D.NT3 with null record;
X : NT4;
I1 : Integer := X.I; -- D.NT3.I
I2 : Integer := D.NT3(X).I; -- D.NT3.I
I3 : Integer := A.T(X).I; -- A.T.I
end A.E;
26.i.7/1 {8652/0102} {AI95-00157-01} D.NT3 can have a component I
because the component I of the parent type is never visible.
The parent component exists, of course, but is never declared
for the type D.NT3. In the child package A.E, the component I
of A.T is visible, but that does not change the fact that the
A.T.I component was never declared for type D.NT3. Thus,
A.E.NT4 does not (visibly) inherit the component I from A.T,
while it does inherit the component I from D.NT3. Of course,
both components exist, and can be accessed by a type
conversion as shown above. This behavior stems from the fact
that every characteristic of a type (including components)
must be declared somewhere in the innermost declarative region
containing the type - if the characteristic is never visible
in that declarative region, it is never declared. Therefore,
such characteristics do not suddenly become available even if
they are in fact visible in some other scope. See 7.3.1 for
more on the rules.
26.i.8/2 * {AI95-00377-01} It is illegal to mention both an explicit
child of an instance, and a child of the generic from which
the instance was instantiated. This is easier to understand
with an example:
26.i.9/2 generic
package G1 is
end G1;
26.i.10/2 generic
package G1.G2 is
end G1.G2;
26.i.11/2 with G1;
package I1 is new G1;
26.i.12/2 package I1.G2 renames ...
26.i.13/2 with G1.G2;
with I1.G2; -- Illegal
package Bad is ...
26.i.14/2 The context clause for Bad is illegal as I1 has an implicit
declaration of I1.G2 based on the generic child G1.G2, as well
as the mention of the explicit child I1.G2. As in the previous
cases, this is illegal only if the context clause makes both
children visible; the explicit child can be mentioned as long
as the generic child is not (and vice-versa).
26.j Note that we need to be careful which things we make "hidden from
all visibility" versus which things we make simply illegal for
names to denote. The distinction is subtle. The rules that
disallow names denoting components within a type declaration (see
3.7) do not make the components invisible at those places, so that
the above rule makes components with the same name illegal. The
same is true for the rule that disallows names denoting formal
parameters within a formal_part (see 6.1).
26.k Discussion: The part about instances is from AI83-00012. The
reason it says "overloadable declarations" is because we don't
want it to apply to type extensions that appear in an instance;
components are not overloadable.
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.
29.a Ramification: An identifier, character_literal or
operator_symbol that occurs in one of the following contexts is
not required to denote a visible or directly visible declaration:
29.b 1. A defining name.
29.c 2. The identifiers or operator_symbol that appear after the
reserved word end in a proper_body. Similarly for "end loop",
etc.
29.d 3. An attribute_designator.
29.e 4. A pragma identifier.
29.f 5. A pragma_argument_identifier.
29.g 6. An identifier specific to a pragma used in a pragma argument.
29.g.1/3 7. {AI05-0183-1} An aspect_mark;
29.g.2/3 8. {AI05-0183-1} An identifier specific to an aspect used in an
aspect_definition.
29.h The visibility rules have nothing to do with the above cases; the
meanings of such things are defined elsewhere. Reserved words are
not identifiers; the visibility rules don't apply to them either.
29.i Because of the way we have defined "declaration", it is possible
for a usage name to denote a subprogram_body, either within that
body, or (for a nonlibrary unit) after it (since the body hides
the corresponding declaration, if any). Other bodies do not work
that way. Completions of type_declarations and deferred constant
declarations do work that way. Accept_statements are never
denoted, although the parameter_specifications in their profiles
can be.
29.j The scope of a subprogram does not start until after its profile.
Thus, the following is legal:
29.k X : constant Integer := 17;
...
package P is
procedure X(Y : in Integer := X);
end P;
29.l The body of the subprogram will probably be illegal, however,
since the constant X will be hidden by then.
29.m The rule is different for generic subprograms, since they are not
overloadable; the following is illegal:
29.n X : constant Integer := 17;
package P is
generic
Z : Integer := X; -- Illegal!
procedure X(Y : in Integer := X); -- Illegal!
end P;
29.o The constant X is hidden from direct visibility by the generic
declaration.
Extensions to Ada 83
29.p Declarations with the same defining name as that of a subprogram
or entry being defined are nevertheless visible within the
subprogram specification or entry declaration.
Wording Changes from Ada 83
29.q The term "visible by selection" is no longer defined. We use the
terms "directly visible" and "visible" (among other things). There
are only two regions of text that are of interest, here: the
region in which a declaration is visible, and the region in which
it is directly visible.
29.r Visibility is defined only for declarations.
Incompatibilities With Ada 95
29.s/2 {AI95-00251-01} Added rules to handle the inheritance and
overriding of multiple homographs for a single type declaration,
in order to support multiple inheritance from interfaces. The new
rules are intended to be compatible with the existing rules so
that programs that do not use interfaces do not change their
legality. However, there is a very rare case where this is not
true:
29.t/2 generic
type T1 is private;
type T2 is private;
package G is
type T is null record;
procedure P (X : T; Y : T1);
procedure P (X : T; Z : T2);
end G;]
29.u/2 package I is new G (Integer, Integer); -- Exports homographs of P.
29.v/2 type D is new I.T; -- Both Ps are inherited.
29.w/2 Obj : D;
29.x/2 P (Obj, Z => 10); -- Legal in Ada 95, illegal in Ada 2005.
29.y/2 The call to P would resolve in Ada 95 by using the parameter name,
while the procedures P would be hidden from all visibility in Ada
2005 and thus would not resolve. This case doesn't seem worth
making the rules any more complex than they already are.
29.z/2 {AI95-00377-01} Amendment Correction: A with_clause is illegal if
it would create a homograph of an implicitly declared generic
child (see 10.1.1). An Ada 95 compiler could have allowed this,
but which unit of the two units involved would be denoted wasn't
specified, so any successful use isn't portable. Removing one of
the two with_clauses involved will fix the problem.
Wording Changes from Ada 95
29.aa/2 {8652/0025} {AI95-00044-01} Corrigendum: Clarified the overriding
rules so that "/=" and statement_identifiers are covered.
29.bb/2 {8652/0026} {AI95-00150-01} Corrigendum: Clarified that is it
never possible for two components with the same name to be
visible; any such program is illegal.
29.cc/2 {AI95-00195-01} {AI95-00408-01} The visibility of an
attribute_definition_clause is defined so that it can be used by
the stream attribute availability rules (see 13.13.2).
29.dd/2 {AI95-00217-06} The visibility of a limited view of a library
package is defined (see 10.1.1).
Wording Changes from Ada 2005
29.ee/4 {AI05-0177-1} {AI12-0157-1} Added wording so that the parameters
of an expression_function_declaration are visible in the return
expression of the function. (It would be pretty useless without
such a rule.)
29.ff/3 {AI05-0183-1} The visibility of an aspect_specification is defined
so that it can be used in various other rules.
8.3.1 Overriding Indicators
1/2 {AI95-00218-03} An overriding_indicator is used to declare that an
operation is intended to override (or not override) an inherited operation.
Syntax
2/2 {AI95-00218-03} overriding_indicator ::= [not] overriding
Legality Rules
3/3 {AI95-00218-03} {AI95-00348-01} {AI95-00397-01} {AI05-0177-1} If an
abstract_subprogram_declaration, null_procedure_declaration, expression_-
function_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;
5.a/3 To be honest: {AI05-0005-1} This doesn't require that the
overriding happen at precisely the place of the declaration or
body; it only requires that the region in which the overriding is
known to have happened includes this place. That is, the
overriding can happen at or before 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.
7.a/2 Discussion: The overriding and not overriding rules differ
slightly. For overriding, we want the indicator to reflect the
overriding state at the place of the declaration; otherwise the
indicator would be "lying". Whether a homograph is implicitly
declared after the declaration (see 7.3.1 to see how this can
happen) has no impact on this check. However, not overriding is
different; "lying" would happen if a homograph declared later
actually is overriding. So, we require this check to take into
account later overridings. That can be implemented either by
looking ahead, or by rechecking when additional operations are
declared.
7.b/2 The "no lying" rules are needed to prevent a
subprogram_declaration and subprogram_body from having
contradictory overriding_indicators.
NOTES
8/2 8 {AI95-00397-01} 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 {AI95-00433-01} 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.
16.a/2 Discussion: In this case, the subprograms are abstract, so
misspellings will get detected anyway. But for other subprograms
(especially when deriving from concrete types), the error might
never be detected, and a body other than the one the programmer
intended might be executed without warning. Thus our new motto:
"Overriding indicators - don't derive a type without them!"
Extensions to Ada 95
16.b/2 {AI95-00218-03} Overriding_indicators are new. These let the
programmer state her overriding intentions to the compiler; if the
compiler disagrees, an error will be produced rather than a hard
to find bug.
Wording Changes from Ada 2005
16.c/3 {AI95-0177-1} Expression functions can have overriding indicators.
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.]
Language Design Principles
1.a If and only if the visibility rules allow P.A, "use P;" should
make A directly visible (barring name conflicts). This means, for
example, that child library units, and generic formals of a formal
package whose formal_package_actual_part is (<>), should be made
visible by a use_clause for the appropriate package.
1.b The rules for use_clauses were carefully constructed to avoid
so-called Beaujolais effects, where the addition or removal of a
single use_clause, or a single declaration in a "use"d package,
would change the meaning of a program from one legal
interpretation to another.
Syntax
2 use_clause ::= use_package_clause | use_type_clause
3 use_package_clause ::= use package_name {, package_name};
4/3 {AI05-0150-1} use_type_clause ::= use [all] type subtype_mark
{, subtype_mark};
Legality Rules
5/2 {AI95-00217-06} A package_name of a use_package_clause shall denote a
nonlimited view of a package.
5.a Ramification: This includes formal packages.
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.a Reason: The exception echoes the similar exception for "immediate
scope (of a declaration)" (see 8.2). It makes use_clauses work
like this:
7.b package P is
type T is range 1..10;
end P;
7.c with P;
package Parent is
private
use P;
X : T;
end Parent;
7.d package Parent.Child is
Y : T; -- Illegal!
Z : P.T;
private
W : T;
end Parent.Child;
7.e The declaration of Y is illegal because the scope of the "use P"
does not include that place, so T is not directly visible there.
The declarations of X, Z, and W are legal.
7.1/2 {AI95-00217-06} 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/3 {AI95-00217-06} {AI05-0150-1} 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. If a
use_type_clause whose scope encloses a place includes the reserved word all,
then the following entities are also potentially use-visible at this place if
the declaration of the entity is visible at this place:
8.1/3 * {AI05-0150-1} Each primitive subprogram of T including each
enumeration literal (if any);
8.2/3 * {AI05-0150-1} Each subprogram that is declared immediately within
the declarative region in which an ancestor type of T is declared and
that operates on a class-wide type that covers T.
8.a/3 Ramification: {AI05-0150-1} Primitive subprograms whose defining
name is an identifier are not made potentially visible by a
use_type_clause unless reserved word all is included. A
use_type_clause without all is only for operators.
8.b The semantics described here should be similar to the semantics
for expanded names given in 4.1.3, "Selected Components" so as to
achieve the effect requested by the "principle of equivalence of
use_clauses and selected_components." Thus, child library units
and generic formal parameters of a formal package are potentially
use-visible when their enclosing package is use'd.
8.c The "visible at that place" part implies that applying a
use_clause to a parent unit does not make all of its children
use-visible - only those that have been made visible by a
with_clause. It also implies that we don't have to worry about
hiding in the definition of "directly visible" - a declaration
cannot be use-visible unless it is visible.
8.d Note that "use type T'Class;" is equivalent to "use type T;",
which helps avoid breaking the generic contract model.
8.3/3 {AI05-0131-1} Certain implicit declarations may become potentially
use-visible in certain contexts as described in 12.6.
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.
11.a Ramification: Overloadable declarations don't cancel each other
out, even if they are homographs, though if they are not
distinguishable by formal parameter names or the presence or
absence of default_expressions, any use will be ambiguous. We only
mention identifiers here, because declarations named by
operator_symbols are always overloadable, and hence never cancel
each other. Direct visibility is irrelevant for
character_literals.
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;
16.a Ramification: In "use X, Y;", Y cannot refer to something made
visible by the "use" of X. Thus, it's not (quite) equivalent to
"use X; use Y;".
16.b If a given declaration is already immediately visible, then a
use_clause that makes it potentially use-visible has no effect.
Therefore, a use_type_clause for a type whose declaration appears
in a place other than the visible part of a package has no effect;
it cannot make a declaration use-visible unless that declaration
is already immediately visible.
16.c "Use type S1;" and "use type S2;" are equivalent if S1 and S2 are
both subtypes of the same type. In particular, "use type S;" and
"use type S'Base;" are equivalent.
16.d Reason: We considered adding a rule that prevented several
declarations of views of the same entity that all have the same
semantics from cancelling each other out. For example, if a
(possibly implicit) subprogram_declaration for "+" is potentially
use-visible, and a fully conformant renaming of it is also
potentially use-visible, then they (annoyingly) cancel each other
out; neither one is use-visible. The considered rule would have
made just one of them use-visible. We gave up on this idea due to
the complexity of the rule. It would have had to account for both
overloadable and nonoverloadable renaming_declarations, the case
where the rule should apply only to some subset of the
declarations with the same defining name, and the case of
subtype_declarations (since they are claimed to be sufficient for
renaming of subtypes).
Extensions to Ada 83
16.e The use_type_clause is new to Ada 95.
Wording Changes from Ada 83
16.f The phrase "omitting from this set any packages that enclose this
place" is no longer necessary to avoid making something visible
outside its scope, because we explicitly state that the
declaration has to be visible in order to be potentially
use-visible.
Wording Changes from Ada 95
16.g/2 {AI95-00217-06} Limited views of packages are not allowed in use
clauses. Defined named in a use clause for use in other limited
view rules (see 10.1.2).
Extensions to Ada 2005
16.h/3 {AI05-0150-1} The use all type version of the use_type_clause is
new to Ada 2012. It works similarly to prefixed views.
Wording Changes from Ada 2005
16.i/3 {AI05-0131-1} Correction: Added wording to allow other
declarations to be potentially use-visible, to support corrections
to formal subprograms.
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.]
1.a.1/2 Glossary entry: A renaming_declaration is a declaration that does
not define a new entity, but instead defines a view of an existing
entity.
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;
Wording Changes from Ada 83
7.a The second sentence of RM83-8.5(3), "At any point where a renaming
declaration is visible, the identifier, or operator symbol of this
declaration denotes the renamed entity." is incorrect. It doesn't
say directly visible. Also, such an identifier might resolve to
something else.
7.b The verbiage about renamings being legal "only if exactly
one...", which appears in RM83-8.5(4) (for objects) and RM83-8.5(7) (for
subprograms) is removed, because it follows from the normal rules
about overload resolution. For language lawyers, these facts are
obvious; for programmers, they are irrelevant, since failing these
tests is highly unlikely.
8.5.1 Object Renaming Declarations
1 [An object_renaming_declaration is used to rename an object.]
Syntax
2/3 {AI95-00230-01} {AI95-00423-01} {AI05-0183-1}
object_renaming_declaration ::=
defining_identifier : [null_exclusion] subtype_mark
renames object_name
[aspect_specification];
| defining_identifier : access_definition renames object_name
[aspect_specification];
Name Resolution Rules
3/2 {AI95-00230-01} {AI95-00254-01} {AI95-00409-01} 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.
3.a Reason: A previous version of Ada 9X used the usual "expected
type" wording:
"The expected type for the object_name is that determined by the
subtype_mark."
We changed it so that this would be illegal:
3.b X: T;
Y: T'Class renames X; -- Illegal!
3.c When the above was legal, it was unclear whether Y was of type T
or T'Class. Note that we still allow this:
3.d Z: T'Class := ...;
W: T renames F(Z);
3.e where F is a function with a controlling parameter and result.
This is admittedly a bit odd.
3.f Note that the matching rule for generic formal parameters of mode
in out was changed to keep it consistent with the rule for
renaming. That makes the rule different for in vs. in out.
Legality Rules
4 The renamed entity shall be an object.
4.1/2 {AI95-00231-01} {AI95-00409-01} 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 * {AI95-00231-01} {AI95-00409-01} 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 * {AI95-00409-01} shall both be access-to-subprogram types with
subtype conformant designated profiles.
4.4/2 {AI95-00423-01} 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.
4.a/2 Reason: This rule prevents "lying". Null must never be the value
of an object with an explicit null_exclusion. The first bullet is
an assume-the-worst rule which prevents trouble in one obscure
case:
4.b/2 type Acc_I is access Integer;
subtype Acc_NN_I is not null Acc_I;
Obj : Acc_I := null;
4.c/2 generic
B : in out Acc_NN_I;
package Gen is
...
end Gen;
4.d/2 package body Gen is
D : not null Acc_I renames B;
end Gen;
4.e/2 package Inst is new Gen (B => Obj);
4.f/2 Without the first bullet rule, D would be legal, and contain the
value null, because the rule about lying is satisfied for generic
matching (Obj matches B; B does not explicitly state not null),
Legality Rules are not rechecked in the body of any instance, and
the template passes the lying rule as well. The rule is so complex
because it has to apply to formals used in bodies of child
generics as well as in the bodies of generics.
5/3 {8652/0017} {AI95-00184-01} {AI95-00363-01} {AI05-0008-1} The renamed
entity shall not be a subcomponent that depends on discriminants of an object
whose nominal subtype is unconstrained unless the object is known to be
constrained. 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.
5.a Reason: This prevents renaming of subcomponents that might
disappear, which might leave dangling references. Similar
restrictions exist for the Access attribute.
5.a.1/3 {8652/0017} {AI95-00184-01} {AI05-0008-1} The "recheck on
instantiation" requirement on generics is necessary to avoid
renaming of components which could disappear even when the nominal
subtype would prevent the problem:
5.a.2/1 type T1 (D1 : Boolean) is
record
case D1 is
when False =>
C1 : Integer;
when True =>
null;
end case;
end record;
5.a.3/1 generic
type F is new T1;
X : in out F;
package G is
C1_Ren : Integer renames X.C1;
end G;
5.a.4/1 type T2 (D2 : Boolean := False) is new T1 (D1 => D2);
Y : T2;
package I is new G (T2, Y);
Y := (D1 => True); -- Oops! What happened to I.C1_Ren?
5.a.5/3 {AI05-0008-1} In addition, the "known to be constrained" rules
include assume-the-worst rules for generic bodies partially to
prevent such problems.
5.b Implementation Note: Note that if an implementation chooses to
deallocate-then-reallocate on assignment_statements assigning to
unconstrained definite objects, then it cannot represent renamings
and access values as simple addresses, because the above rule does
not apply to all components of such an object.
5.c Ramification: If it is a generic formal object, then the
assume-the-best or assume-the-worst rules are applied as
appropriate.
Static Semantics
6/2 {AI95-00230-01} {AI95-00409-01} 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).]
6.a Discussion: Because the constraints are ignored, it is a good idea
to use the nominal subtype of the renamed object when writing an
object_renaming_declaration.
6.b/2 {AI95-00409-01} If no null_exclusion is given in the renaming, the
object may or may not exclude null. This is similar to the way
that constraints need not match, and constant is not specified.
The renaming defines a view of the renamed entity, inheriting the
original properties.
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;
Wording Changes from Ada 83
8.a The phrase "subtype ... as defined in a corresponding object
declaration, component declaration, or component subtype
indication," from RM83-8.5(5), is incorrect in Ada 95; therefore
we removed it. It is incorrect in the case of an object with an
indefinite unconstrained nominal subtype.
Incompatibilities With Ada 95
8.b/2 {AI95-00363-01} Aliased variables are not necessarily constrained
in Ada 2005 (see 3.6). Therefore, a subcomponent of an aliased
variable may disappear or change shape, and renaming such a
subcomponent thus is illegal, while the same operation would have
been legal in Ada 95. Note that most allocated objects are still
constrained by their initial value (see 4.8), and thus have no
change in the legality of renaming for them. For example, using
the type T2 of the previous example:
8.c/2 AT2 : aliased T2;
C1_Ren : Integer renames AT2.C1; -- Illegal in Ada 2005, legal in Ada 95
AT2 := (D1 => True); -- Raised Constraint_Error in Ada 95,
-- but does not in Ada 2005, so C1_Ren becomes
-- invalid when this is assigned.
Extensions to Ada 95
8.d/2 {AI95-00230-01} {AI95-00231-01} {AI95-00254-01} {AI95-00409-01} A
renaming can have an anonymous access type. In that case, the
accessibility of the renaming is that of the original object
(accessibility is not lost as it is for assignment to a component
or stand-alone object).
8.e/2 {AI95-00231-01} {AI95-00423-01} A renaming can have a
null_exclusion; if so, the renamed object must also exclude null,
so that the null_exclusion does not lie. On the other hand, if the
renaming does not have a null_exclusion. it excludes null if the
renamed object does.
Wording Changes from Ada 95
8.f/2 {8652/0017} {AI95-00184-01} Corrigendum: Fixed to forbid renamings
of depends-on-discriminant components if the type might be
definite.
Incompatibilities With Ada 2005
8.g/3 {AI05-0008-1} Correction: Simplified the description of when a
discriminant-dependent component is allowed to be renamed - it's
now simply when the object is known to be constrained. This fixes
a confusion as to whether a subcomponent of an object that is not
certain to be constrained can be renamed. The fix introduces an
incompatibility, as the rule did not apply in Ada 95 if the prefix
was a constant; but it now applies no matter what kind of object
is involved. The incompatibility is not too bad, since most kinds
of constants are known to be constrained.
Extensions to Ada 2005
8.h/3 {AI05-0183-1} An optional aspect_specification can be used in an
object_renaming_declaration. This is described in 13.1.1.
8.5.2 Exception Renaming Declarations
1 [An exception_renaming_declaration is used to rename an exception.]
Syntax
2/3 {AI05-0183-1} exception_renaming_declaration ::=
defining_identifier : exception renames exception_name
[aspect_specification];
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
Extensions to Ada 2005
6.a/3 {AI05-0183-1} An optional aspect_specification can be used in an
exception_renaming_declaration. This is described in 13.1.1.
8.5.3 Package Renaming Declarations
1 [A package_renaming_declaration is used to rename a package.]
Syntax
2/3 {AI05-0183-1} package_renaming_declaration ::=
package defining_program_unit_name renames package_name
[aspect_specification];
Legality Rules
3 The renamed entity shall be a package.
3.1/2 {AI95-00217-06} {AI95-00412-01} 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.
3.a.1/2 Discussion: The use of a renaming that designates a limited view
is restricted to locations where we know whether the view is
limited or nonlimited (based on a with_clause). We don't want to
make an implicit limited view, as those are not transitive like a
regular view. Implementations should be able to see all limited
views needed based on the context_clause.
Static Semantics
4 A package_renaming_declaration declares a new view [of the renamed
package].
4.1/2 {AI95-00412-01} [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).]
4.a.1/2 Proof: This rule is found in 8.3, "Visibility".
Examples
5 Example of renaming a package:
6 package TM renames Table_Manager;
Wording Changes from Ada 95
6.a/2 {AI95-00217-06} {AI95-00412-01} Uses of renamed limited views of
packages can only be used within the scope of a with_clause for
the renamed package.
Extensions to Ada 2005
6.b/3 {AI05-0183-1} An optional aspect_specification can be used in a
package_renaming_declaration. This is described in 13.1.1.
8.5.4 Subprogram Renaming Declarations
1/3 {AI05-0299-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].
1.a/3 Ramification: {AI05-0299-1} A renaming-as-body is a declaration,
as defined in Clause 3.
Syntax
2/3 {AI95-00218-03} {AI05-0183-1} subprogram_renaming_declaration ::=
[overriding_indicator]
subprogram_specification renames callable_entity_name
[aspect_specification];
Name Resolution Rules
3 The expected profile for the callable_entity_name is the profile given in
the subprogram_specification.
Legality Rules
4/3 {AI05-0239-1} The profile of a renaming-as-declaration shall be mode
conformant, with that of the renamed callable entity.
4.1/2 {AI95-00423-01} 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.
4.a/2 Reason: This rule prevents "lying". Null must never be the value
of a parameter or result with an explicit null_exclusion. The
first bullet is an assume-the-worst rule which prevents trouble in
generic bodies (including bodies of child units) when the formal
subtype excludes null implicitly.
5/3 {8652/0027} {8652/0028} {AI95-00135-01} {AI95-00145-01} {AI05-0239-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.a/1 Reason: The otherwise part of the second sentence is to allow an
implementation of a renaming-as-body as a single jump instruction
to the target subprogram. Among other things, this prevents a
subprogram from being completed with a renaming of an entry. (In
most cases, the target of the jump can be filled in at link time.
In some cases, such as a renaming of a name like "A(I).all", an
indirect jump is needed. Note that the name is evaluated at
renaming time, not at call time.)
5.a.1/1 {8652/0028} {AI95-00145-01} The first part of the second sentence
is intended to allow renaming-as-body of predefined operators
before the subprogram_declaration is frozen. For some types (such
as integer types), the parameter type for operators is the base
type, and it would be very strange for
function Equal (A, B : in T) return Boolean;
function Equal (A, B : in T) return Boolean renames "=";
to be illegal. (Note that predefined operators cannot be renamed
this way after the subprogram_declaration is frozen, as they have
convention Intrinsic.)
5.b/1 The first sentence is the normal rule for completions of
subprogram_declarations.
5.c Ramification: An entry_declaration, unlike a
subprogram_declaration, cannot be completed with a renaming_-
declaration. Nor can a generic_subprogram_declaration.
5.d The syntax rules prevent a protected subprogram declaration from
being completed by a renaming. This is fortunate, because it
allows us to avoid worrying about whether the implicit protected
object parameter of a protected operation is involved in the
conformance rules.
5.d.1/1 Reason: {8652/0027} {AI95-00135-01} Circular renames before
freezing is illegal, as the compiler would not be able to
determine the convention of the subprogram. Other circular renames
are handled below; see Bounded (Run-Time) Errors.
5.1/2 {AI95-00228-01} The callable_entity_name of a renaming shall not denote
a subprogram that requires overriding (see 3.9.3).
5.d.2/2 Reason: {AI95-00228-01} Such a rename cannot be of the inherited
subprogram (which requires overriding because it cannot be
called), and thus cannot squirrel away a subprogram (see below).
That would be confusing, so we make it illegal. The renaming is
allowed after the overriding, as then the name will denote the
overriding subprogram, not the inherited one.
5.2/2 {AI95-00228-01} The callable_entity_name of a renaming-as-body shall not
denote an abstract subprogram.
5.d.3/2 Reason: {AI95-00228-01} Such a subprogram has no body, so it
hardly can replace one in the program.
6 A name that denotes a formal parameter of the subprogram_specification is
not allowed within the callable_entity_name.
6.a Reason: This is to prevent things like this:
6.b function F(X : Integer) return Integer renames Table(X).all;
6.c A similar rule in 6.1 forbids things like this:
6.d function F(X : Integer; Y : Integer := X) return Integer;
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.
7.a To be honest: When renaming an entry as a procedure, the
compile-time rules apply as if the new view is a procedure, but
the run-time semantics of a call are that of an entry call.
7.b Ramification: For example, it is illegal for the
entry_call_statement of a timed_entry_call to call the new view.
But what looks like a procedure call will do things like barrier
waiting.
7.b.1/3 {8652/0105} {AI95-00211-01} {AI95-00228-01} {AI05-0095-1} All
properties of the renamed entity are inherited by the new view
unless otherwise stated by this International Standard. In
particular, if the renamed entity is abstract, the new view also
is abstract. Similarly, if the renamed entity is not a program
unit, then neither is the renaming. (Implicitly declared
subprograms are not program units, see 10.1).
Dynamic Semantics
7.1/1 {8652/0014} {AI95-00064-01} 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.
7.b.2/1 Ramification: This implies that the subprogram completed by the
renaming-as-body has its own elaboration check.
8/3 {AI05-0123-1} 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. A corresponding rule applies to
a call on a renaming of a predefined equality operator for an untagged record
type.
8.a Discussion: Note that whether or not the renaming is itself
primitive has nothing to do with the renamed subprogram.
8.b/3 {AI05-0123-1} Note that the above rule is only for tagged types
and equality of untagged record types.
8.c Consider the following example:
8.d package P is
type T is tagged null record;
function Predefined_Equal(X, Y : T) return Boolean renames "=";
private
function "="(X, Y : T) return Boolean; -- Override predefined "=".
end P;
8.e with P; use P;
package Q is
function User_Defined_Equal(X, Y : T) return Boolean renames P."=";
end Q;
8.f A call on Predefined_Equal will execute the predefined equality
operator of T, whereas a call on User_Defined_Equal will execute
the body of the overriding declaration in the private part of P.
8.g Thus a renaming allows one to squirrel away a copy of an inherited
or predefined subprogram before later overriding it.
Bounded (Run-Time) Errors
8.1/1 {8652/0027} {AI95-00135-01} 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.
8.g.1/1 Reason: {8652/0027} {AI95-00135-01} This has to be a bounded
error, as it is possible for a renaming-as-body appearing in a
package body to cause this problem. Thus it is not possible in
general to detect this problem at compile time.
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 nonprimitive renaming of a
primitive subprogram.
12.a Reason: A subprogram_renaming_declaration could more properly be
called renaming_as_subprogram_declaration, since you're renaming
something as a subprogram, but you're not necessarily renaming a
subprogram. But that's too much of a mouthful. Or, alternatively,
we could call it a callable_entity_renaming_declaration, but
that's even worse. Not only is it a mouthful, it emphasizes the
entity being renamed, rather than the new view, which we think is
a bad idea. We'll live with the oddity.
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
Extensions to Ada 95
21.a/2 {8652/0028} {AI95-00145-01} Corrigendum: Allowed a
renaming-as-body to be just mode conformant with the specification
if the subprogram is not yet frozen.
21.b/2 {AI95-00218-03} Overriding_indicator (see 8.3.1) is optionally
added to subprogram renamings.
Wording Changes from Ada 95
21.c/2 {8652/0014} {AI95-00064-01} Corrigendum: Described the semantics
of renaming-as-body, so that the location of elaboration checks is
clear.
21.d/2 {8652/0027} {AI95-00135-01} Corrigendum: Clarified that circular
renaming-as-body is illegal (if it can be detected in time) or a
bounded error.
21.e/2 {AI95-00228-01} Amendment Correction: Clarified that renaming a
shall-be-overridden subprogram is illegal, as well as
renaming-as-body an abstract subprogram.
21.f/2 {AI95-00423-01} Added matching rules for null_exclusions.
Inconsistencies With Ada 2005
21.f.1/3 {AI05-0123-1} Renaming of user-defined untagged record equality is
now defined to call the overridden body so long as the overriding
occurred before the renames. This could change the body called in
unusual cases; the change is necessary to preserve the principle
that the body called for an explicit call to "=" (via a renames in
this case) is the same as the one inherited for a derived type and
used in generics. Note that any renamings before the overriding
will be unchanged. Any differences caused by the change will be
rare and most likely will fix a bug.
Extensions to Ada 2005
21.g/3 {AI05-0183-1} An optional aspect_specification can be used in a
subprogram_renaming_declaration. This is described in 13.1.1.
8.5.5 Generic Renaming Declarations
1 [A generic_renaming_declaration is used to rename a generic unit.]
Syntax
2/3 {AI05-0183-1} generic_renaming_declaration ::=
generic package defining_program_unit_name
renames generic_package_name
[aspect_specification];
| generic procedure defining_program_unit_name
renames generic_procedure_name
[aspect_specification];
| generic function defining_program_unit_name
renames generic_function_name
[aspect_specification];
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
Extensions to Ada 83
7.a Renaming of generic units is new to Ada 95. It is particularly
important for renaming child library units that are generic units.
For example, it might be used to rename
Numerics.Generic_Elementary_Functions as simply
Generic_Elementary_Functions, to match the name for the
corresponding Ada-83-based package.
Wording Changes from Ada 83
7.b The information in RM83-8.6, "The Package Standard," has been
updated for the child unit feature, and moved to Annex A, except
for the definition of "predefined type," which has been moved to
3.2.1.
Extensions to Ada 2005
7.c/3 {AI05-0183-1} An optional aspect_specification can be used in a
generic_renaming_declaration. This is described in 13.1.1.
8.6 The Context of Overload Resolution
1/3 {AI05-0299-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 subclause 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 nonoverloading 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.]
Language Design Principles
3.a The type resolution rules are intended to minimize the need for
implicit declarations and preference rules associated with
implicit conversion and dispatching operations.
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.
6.a Ramification: A loop_parameter_specification is a declaration, and
hence a complete context.
7 * A statement.
8 * A pragma_argument_association.
8.a Reason: We would make it the whole pragma, except that certain
pragma arguments are allowed to be ambiguous, and ambiguity
applies to a complete context.
9/4 * {AI12-0040-1} The selecting_expression of a case_statement or
case_expression.
9.a Ramification: This means that the expression is resolved without
looking at the choices.
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
11.a Ramification: Syntactic categories is plural here, because there
are lots of trivial productions - an expression might also be all
of the following, in this order: identifier, name, primary,
factor, term, simple_expression, and relation. Basically, we're
trying to capture all the information in the parse tree here,
without using compiler-writer's jargon like "parse tree".
12 * for each usage name, which declaration it denotes (and, therefore,
which view and which entity it denotes); and
12.a/2 Ramification: {AI95-00382-01} In most cases, a usage name denotes
the view declared by the denoted declaration. However, in certain
cases, a usage name that denotes a declaration and appears inside
the declarative region of that same declaration, denotes the
current instance of the declaration. For example, within a
task_body other than in an access_definition, a usage name that
denotes the task_type_declaration denotes the object containing
the currently executing task, and not the task type declared by
the declaration.
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.
13.a Ramification: Unfortunately, we are not confident that the above
list is complete. We'll have to live with that.
13.b To be honest: For "possible" interpretations, the above
information is tentative.
13.c Discussion: A possible interpretation (an input to overload
resolution) contains information about what a usage name might
denote, but what it actually does denote requires overload
resolution to determine. Hence the term "tentative" is needed for
possible interpretations; otherwise, the definition would be
circular.
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.]
14.a To be honest: One rule that falls into this category, but does not
use the above-mentioned magic words, is the rule about numbers of
parameter associations in a call (see 6.4).
14.b Ramification: The Name Resolution Rules are the ones that appear
under the Name Resolution Rules heading. Some Syntax Rules are
written in English, instead of BNF. No rule is a Syntax Rule or
Name Resolution Rule unless it appears under the appropriate
heading.
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:
16.a Ramification: As explained below, a pragma argument is allowed to
be ambiguous, so it can denote several declarations, and all of
the views declared by those declarations.
17/3 * {AI95-00382-01} {AI05-0287-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. Similarly, if a usage name appears within
the declarative region of a subtype_declaration and denotes that same
subtype_declaration, then it denotes the current instance of the
subtype. These rules do 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.
17.a/2 Reason: {AI95-00382-01} This is needed, for example, for
references to the Access attribute from within the
type_declaration. Also, within a task_body or protected_body, we
need to be able to denote the current task or protected object.
(For a single_task_declaration or single_protected_declaration,
the rule about current instances is not needed.) We exclude
anonymous access types so that they can be used to create
self-referencing types in the natural manner (otherwise such types
would be illegal).
17.b/2 Discussion: {AI95-00382-01} The phrase "within the subtype_mark
" in the "this rule does not apply" part is intended to cover a
case like access T'Class appearing within the declarative region
of T: here T denotes the type, not the current instance.
17.1/4 {AI12-0068-1} Within an aspect_specification for a type or subtype,
the current instance represents a value of the type; it is not an
object. The nominal subtype of this value is given by the subtype
itself (the first subtype in the case of a type_declaration), prior to
applying any predicate specified directly on the type or subtype. If
the type or subtype is by-reference, the associated object with the
value is the object associated (see 6.2) with the execution of the
usage name.
17.c/4 Ramification: For the purposes of Legality Rules, the current
instance acts as a value within an aspect_specification. It might
really be an object (and has to be for a by-reference type), but
that isn't discoverable by direct use of the name of the current
instance.
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.
18.a To be honest: The current instance of a generic unit is the
instance created by whichever generic_instantiation is of interest
at any given time.
18.b Ramification: Within a generic_formal_part, a name that denotes
the generic_declaration denotes the generic unit, which implies
that it is not overloadable.
19 A usage name that denotes a view also denotes the entity of that view.
19.a Ramification: Usually, a usage name denotes only one declaration,
and therefore one view and one entity.
20/2 {AI95-00231-01} 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:]
20.a Ramification: Expected types are defined throughout the RM95. The
most important definition is that, for a subprogram, the expected
type for the actual parameter is the type of the formal parameter.
20.b The type resolution rules are trivial unless either the actual or
expected type is universal, class-wide, or of an anonymous access
type.
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.
21.a Ramification: This matching rule handles (among other things)
cases like the Val attribute, which denotes a function that takes
a parameter of type universal_integer.
21.b/1 The last part of the rule, "or to a universal type that covers the
class" implies that if the expected type for an expression is
universal_fixed, then an expression whose type is universal_real
(such as a real literal) is OK.
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:
22.a Ramification: This rule is not intended to create a preference for
the specific type - such a preference would cause Beaujolais
effects.
23 * to T'Class; or
23.a Ramification: This will only be legal as part of a call on a
dispatching operation; see 3.9.2, "
Dispatching Operations of Tagged Types". Note that that rule is
not a Name Resolution Rule.
24 * to a universal type that covers T; or
25/2 * {AI95-00230-01} {AI95-00231-01} {AI95-00254-01} {AI95-00409-01}
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.a/2 This paragraph was deleted.{AI95-00409-01}
25.b Ramification: The case where the actual is access-to-D'Class will
only be legal as part of a call on a dispatching operation; see
3.9.2, "Dispatching Operations of Tagged Types". Note that that
rule is not a Name Resolution Rule.
25.1/3 * {AI05-0149-1} when T is a named general access-to-object type (see
3.10) with designated type D, to an anonymous access-to-object
type whose designated type covers or is covered by D; or
25.2/3 * {AI95-00254-01} {AI95-00409-01} {AI05-0239-1} 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.
26.a/3 Ramification: {AI05-0239-1} The parameter and result subtypes are
not used in overload resolution. Only type conformance of profiles
is considered during overload resolution. Legality rules generally
require at least mode conformance in addition, but those rules are
not used in overload resolution.
Legality Rules
27/2 {AI95-00332-01} 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.
27.a/2 Ramification: {AI95-00230-01} For example, the expected type for a
string literal is required to be a single string type. But the
expected type for the operand of a type_conversion is any type.
Therefore, a string literal is not allowed as the operand of a
type_conversion. This is true even if there is only one string
type in scope (which is never the case). The reason for these
rules is so that the compiler will not have to search "
everywhere" to see if there is exactly one type in a class in scope.
27.b/2 Discussion: {AI95-00332-01} The first sentence is carefully worded
so that it only mentions "expected type" as part of identifying
the interesting case, but doesn't require that the context
actually provide such an expected type. This allows such
constructs to be used inside of constructs that don't provide an
expected type (like qualified expressions and renames). Otherwise,
such constructs wouldn't allow aggregates, 'Access, and so on.
27.1/4 {AI05-0102-1} {AI05-0149-1} {AI05-0299-1} {AI12-0039-1} Other than for
the tested_simple_expression of a membership test, if the expected type for a
name or expression is not the same as the actual type of the name or
expression, the actual type shall be convertible to the expected type (see
4.6); further, if the expected type is a named access-to-object type with
designated type D1 and the actual type is an anonymous access-to-object type
with designated type D2, then D1 shall cover D2, and the name or expression
shall denote a view with an accessibility level for which the statically
deeper relationship applies[; in particular it shall not denote an access
parameter nor a stand-alone access object].
27.c/3 Reason: This rule prevents an implicit conversion that would be
illegal if it was an explicit conversion. For instance, this
prevents assigning an access-to-constant value into a stand-alone
anonymous access-to-variable object. It also covers convertibility
of the designated type and accessibility checks.
27.d/3 The rule also minimizes cases of implicit conversions when the tag
check or the accessibility check might fail. We word it this way
because access discriminants should also be disallowed if their
enclosing object is designated by an access parameter.
27.e/3 Ramification: This rule does not apply to expressions that don't
have expected types (such as the operand of a qualified expression
or the expression of a renames). We don't need a rule like this in
those cases, as the type needs to be the same; there is no
implicit conversion.
28 A complete context shall have at least one acceptable interpretation; if
there is exactly one, then that one is chosen.
28.a Ramification: This, and the rule below about ambiguity, are the
ones that suck in all the Syntax Rules and Name Resolution Rules
as compile-time rules. Note that this and the ambiguity rule have
to be Legality Rules.
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.
29.a Reason: The reason for this preference is so that expressions
involving literals and named numbers can be unambiguous. For
example, without the preference rule, the following would be
ambiguous:
29.b/1 N : constant := 123;
if N > 100 then -- Preference for root_integer ">" operator.
...
end if;
29.1/3 {AI05-0149-1} Similarly, there is a preference for the equality
operators of the universal_access type (see 4.5.2). If two acceptable
interpretations of a constituent of a complete context differ only in that one
is for an equality operator of the universal_access type, and the other is
not, the interpretation using the equality operator of the universal_access
type is preferred.
29.c/3 Reason: This preference is necessary because of implicit
conversion from an anonymous access type to a named access type,
which would allow the equality operator of any named access type
to be used to compare anonymous access values (and that way lies
madness).
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.
32.a/3 Ramification: {AI95-00224-01} {AI05-0229-1} This applies to
Inline, Suppress, Import, Export, and Convention pragmas. For
example, it is OK to say "pragma Export(C, Entity_Name => P.Q);",
even if there are two directly visible P's, and there are two Q's
declared in the visible part of each P. In this case, P.Q denotes
four different declarations. This rule also applies to certain
pragmas defined in the Specialized Needs Annexes. It almost
applies to Pure, Elaborate_Body, and Elaborate_All pragmas, but
those can't have overloading for other reasons. Note that almost
all of these pragmas are obsolescent (see J.10 and J.15), and a
major reason is that this rule has proven to be too broad in
practice (it is common to want to specify something on a single
subprogram of an overloaded set, that can't be done easily with
this rule). Aspect_specifications, which are given on individual
declarations, are preferred in Ada 2012.
32.b Note that if a pragma argument denotes a call to a callable
entity, rather than the entity itself, this exception does not
apply, and ambiguity is disallowed.
32.c Note that we need to carefully define which pragma-related rules
are Name Resolution Rules, so that, for example, a pragma Inline
does not pick up subprograms declared in enclosing declarative
regions, and therefore make itself illegal.
32.d We say "statically denotes" in the above rule in order to avoid
having to worry about how many times the name is evaluated, in
case it denotes more than one callable entity.
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).
Incompatibilities With Ada 83
34.a The new preference rule for operators of root numeric types is
upward incompatible, but only in cases that involved Beaujolais
effects in Ada 83. Such cases are ambiguous in Ada 95.
Extensions to Ada 83
34.b The rule that allows an expected type to match an actual
expression of a universal type, in combination with the new
preference rule for operators of root numeric types, subsumes the
Ada 83 "implicit conversion" rules for universal types.
Wording Changes from Ada 83
34.c In Ada 83, it is not clear what the "syntax rules" are. AI83-00157
states that a certain textual rule is a syntax rule, but it's
still not clear how one tells in general which textual rules are
syntax rules. We have solved the problem by stating exactly which
rules are syntax rules - the ones that appear under the "Syntax
" heading.
34.d RM83 has a long list of the "forms" of rules that are to be used
in overload resolution (in addition to the syntax rules). It is
not clear exactly which rules fall under each form. We have solved
the problem by explicitly marking all rules that are used in
overload resolution. Thus, the list of kinds of rules is
unnecessary. It is replaced with some introductory (intentionally
vague) text explaining the basic idea of what sorts of rules are
overloading rules.
34.e/3 {AI05-0299-1} It is not clear from RM83 what information is
embodied in a "meaning" or an "interpretation." "Meaning" and "
interpretation" were intended to be synonymous; we now use the
latter only in defining the rules about overload resolution. "
Meaning" is used only informally. This subclause attempts to
clarify what is meant by "interpretation."
34.f For example, RM83 does not make it clear that overload resolution
is required in order to match subprogram_bodies with their
corresponding declarations (and even to tell whether a given
subprogram_body is the completion of a previous declaration).
Clearly, the information needed to do this is part of the "
interpretation" of a subprogram_body. The resolution of such
things is defined in terms of the "expected profile" concept. Ada
95 has some new cases where expected profiles are needed - the
resolution of P'Access, where P might denote a subprogram, is an
example.
34.g RM83-8.7(2) might seem to imply that an interpretation embodies
information about what is denoted by each usage name, but not
information about which syntactic category each construct belongs
to. However, it seems necessary to include such information, since
the Ada grammar is highly ambiguous. For example, X(Y) might be a
function_call or an indexed_component, and no
context-free/syntactic information can tell the difference. It
seems like we should view X(Y) as being, for example, "
interpreted as a function_call" (if that's what overload
resolution decides it is). Note that there are examples where the
denotation of each usage name does not imply the syntactic
category. However, even if that were not true, it seems that
intuitively, the interpretation includes that information. Here's
an example:
34.h type T;
type A is access T;
type T is array(Integer range 1..10) of A;
I : Integer := 3;
function F(X : Integer := 7) return A;
Y : A := F(I); -- Ambiguous? (We hope so.)
34.i/1 Consider the declaration of Y (a complete context). In the above
example, overload resolution can easily determine the declaration,
and therefore the entity, denoted by Y, A, F, and I. However,
given all of that information, we still don't know whether F(I) is
a function_call or an indexed_component whose prefix is a
function_call. (In the latter case, it is equivalent to
F(7).all(I).)
34.j It seems clear that the declaration of Y ought to be considered
ambiguous. We describe that by saying that there are two
interpretations, one as a function_call, and one as an
indexed_component. These interpretations are both acceptable to
the overloading rules. Therefore, the complete context is
ambiguous, and therefore illegal.
34.k It is the intent that the Ada 95 preference rule for root numeric
operators is more locally enforceable than that of RM83-4.6(15).
It should also eliminate interpretation shifts due to the addition
or removal of a use_clause (the so called Beaujolais effect).
34.l/2 {AI95-00114-01} RM83-8.7 seems to be missing some complete
contexts, such as pragma_argument_associations, declarative_items
that are not declarations or aspect_clauses, and context_items. We
have added these, and also replaced the "must be determinable"
wording of RM83-5.4(3) with the notion that the expression of a
case_statement is a complete context.
34.m Cases like the Val attribute are now handled using the normal type
resolution rules, instead of having special cases that explicitly
allow things like "any integer type."
Incompatibilities With Ada 95
34.n/2 {AI95-00409-01} Ada 95 allowed name resolution to distinguish
between anonymous access-to-variable and access-to-constant types.
This is similar to distinguishing between subprograms with in and
in out parameters, which is known to be bad. Thus, that part of
the rule was dropped as we now have anonymous access-to-constant
types, making this much more likely.
34.o/2 type Cacc is access constant Integer;
procedure Proc (Acc : access Integer) ...
procedure Proc (Acc : Cacc) ...
List : Cacc := ...;
Proc (List); -- OK in Ada 95, ambiguous in Ada 2005.
34.p/2 If there is any code like this (such code should be rare), it will
be ambiguous in Ada 2005.
Extensions to Ada 95
34.q/2 {AI95-00230-01} {AI95-00231-01} {AI95-00254-01} Generalized the
anonymous access resolution rules to support the new capabilities
of anonymous access types (that is, access-to-subprogram and
access-to-constant).
34.r/2 {AI95-00382-01} We now allow the creation of self-referencing
types via anonymous access types. This is an extension in unusual
cases involving task and protected types. For example:
34.s/2 task type T;
34.t/2 task body T is
procedure P (X : access T) is -- Illegal in Ada 95, legal in Ada 2005
...
end P;
begin
...
end T;
Wording Changes from Ada 95
34.u/2 {AI95-00332-01} Corrected the "single expected type" so that it
works in contexts that don't have expected types (like object
renames and qualified expressions). This fixes a hole in Ada 95
that appears to prohibit using aggregates, 'Access, character
literals, string literals, and allocators in qualified
expressions.
Incompatibilities With Ada 2005
34.v/3 {AI05-0149-1} Implicit conversion is now allowed from anonymous
access-to-object types to general access-to-object types. Such
conversions can make calls ambiguous. That can only happen when
there are two visible subprograms with the same name and have
profiles that differ only by a parameter that is of a named or
anonymous access type, and the actual argument is of an anonymous
access type. This should be rare, as many possible calls would be
ambiguous even in Ada 2005 (including allocators and any actual of
a named access type if the designated types are the same).
Extensions to Ada 2005
34.w/3 {AI05-0149-1} Implicit conversion is allowed from anonymous
access-to-object types to general access-to-object types if the
designated type is convertible and runtime checks are minimized.
See also the incompatibilities section.
Wording Changes from Ada 2005
34.x/3 {AI05-0102-1} Added a requirement here that implicit conversions
are convertible to the appropriate type. This rule was scattered
about the Standard, we moved a single generalized version here.
Inconsistencies With Ada 2012
34.y/4 {AI12-0068-1} Corrigendum: Added a rule to specify that the
current instance of a type or subtype is a value within an
aspect_specification. This could be inconsistent if a predicate or
invariant uses the Constrained attribute on the current instance
(it will always be False now, while it might have returned True in
original Ada 2012). More likely, a usage of a current instance as
a prefix of an attribute will become illegal (such as Size or
Alignment). Any such code is very tricky. Moreover, as this is a
new feature of Ada 2012, there are not that many predicates and
invariants, and the ones that exist are very unlikely to be this
tricky. Thus we do not believe that there will be any practical
effect to this change, other than to explicitly allow common
implementation strategies.
Wording Changes from Ada 2012
34.z/4 {AI12-0040-1} Corrigendum: Added wording to clarify that the
selecting_expression of a case_expression is a complete context,
just like that of a case_statement. Clearly, everyone expects
these to work the same way. Moreover, since it would be a lot of
extra work to treat case_expressions differently, it is quite
unlikely that any compiler would implement the much more
complicated resolution necessary (and we are not aware of any that
did). Therefore, we didn't document this as a potential
incompatibility.
Generated by dwww version 1.15 on Sat May 18 13:02:44 CEST 2024.