Contents Index Search 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 derived type.
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 Search Previous Next Legal