Contents Index Previous Next
8.5.1 Object Renaming Declarations
is used to rename an object.]
: subtype_mark renames object_name
Name Resolution Rules
The type of the object_name
shall resolve to the type determined by the subtype_mark.
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:
Y: T'Class renames X; -- Illegal!
the above was legal, it was unclear whether Y was of type T or T'Class.
Note that we still allow this:
Z: T'Class := ...;
W: T renames F(Z);
where F is a function with a controlling
parameter and result. This is admittedly a bit odd.
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.
The renamed entity shall be an object.
The renamed entity shall not be a subcomponent that depends on discriminants
of a variable whose nominal subtype is unconstrained, unless this subtype is
indefinite, or the variable is aliased. A slice
of an array shall not be renamed if this restriction disallows renaming of the
array. In addition to the places where Legality Rules normally apply, these
rules apply also in the private part of an instance of a generic unit. These
rules also apply for a renaming that appears in the body of a generic unit,
with the additional requirement that even if the nominal subtype of the variable
is indefinite, its type shall not be a descendant of an untagged generic formal
Reason: This prevents renaming
of subcomponents that might disappear, which might leave dangling references.
Similar restrictions exist for the Access attribute.
The "recheck on instantiation" and "assume-the-worst in the
body" restrictions on generics are necessary to avoid renaming of components
which could disappear even when the nominal subtype would prevent the problem:
type T1 (D1 : Boolean) is
case D1 is
when False =>
C1 : Integer;
when True =>
type F is new T1;
X : in out F;
package G is
C1_Ren : Integer renames X.C1;
type T2 (D2 : Boolean := True) is new T1 (D1 => D2);
Y : T2;
package I is new G (T2, Y);
Y := (D1 => True); -- Oops! What happened to I.C1_Ren?
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.
Ramification: If it is
a generic formal object, then the assume-the-best or assume-the-worst
rules are applied as appropriate.
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 constraints that apply to an object are not affected by
renaming (any constraint implied by the subtype_mark
of the object_renaming_declaration
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.
Example of renaming
L : Person renames Leftmost_Person; -- see 3.10.1
L.Age := L.Age + 1;
Wording Changes from Ada 83
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.
Contents Index Previous Next Legal