8.5 Renaming Declarations
Term entry: renaming
— declaration that does not define a new entity, but instead defines
a new view of an existing entity
Syntax
Dynamic Semantics
The elaboration of a
renaming_declaration
evaluates the
name
that follows the reserved word
renames and thereby determines
the view and entity denoted by this name
(the
renamed view and
renamed entity). [A
name
that denotes the
renaming_declaration
denotes (a new view of) the renamed entity.]
NOTE 1 {
AI12-0442-1}
Renaming
can 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
can need not
be visible at
different the
same places.
This paragraph was
deleted.NOTE 2 {
AI12-0427-1}
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.
NOTE 3 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.
Ada 2005 and 2012 Editions sponsored in part by Ada-Europe