8.5 Renaming Declarations
Glossary entry: {
Renaming} A
renaming_declaration
is a declaration that does not define a new entity, but instead defines
a view of an existing entity.
Syntax
Dynamic Semantics
{elaboration (renaming_declaration)
[partial]} 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
{renamed
view} {renamed
entity} (the
renamed view and
renamed
entity). [A
name
that denotes the
renaming_declaration
denotes (a new view of) the renamed entity.]
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.
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.
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
subtype Mode is Ada.Text_IO.File_Mode;
Wording Changes from Ada 83
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.
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.
Sponsored by Ada-Europe