8.5.1 Object Renaming Declarations
Name Resolution Rules
In the case where the type is defined by an access_definition,
the type of the object_name
shall resolve 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
previous version of Ada 9X used the usual “expected type”
“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!
When 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.
The renamed entity shall be an object or value..
shall both be access-to-object types with statically matching designated
subtypes and with both or neither being access-to-constant types; or
shall both be access-to-subprogram types with subtype conformant designated
if the object_name
denotes a generic formal object
of mode in out
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 that the formal
object of G
shall have a null_exclusion
if otherwise, the
statically denotes a call of a generic formal function
of G, then the declaration of the result of that function shall
have a null_exclusion 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
These rules prevent This
must never be the
value of an object with an explicit null_exclusion
The bullets are first
bullet is an
assume-the-worst rules that
prevent rule which prevents
in two one
obscure cases case
type Acc_I is access Integer;
subtype Acc_NN_I is not null Acc_I;
Obj : Acc_I := null;
B : in out Acc_NN_I;
package Gen is
package body Gen is
D : not null Acc_I renames B;
package Inst is new Gen (B => Obj);
Without the first bullet rule, D would be legal, and contain the value
, because the rule about lying is satisfied for generic matching
(Obj matches B; B does not explicitly state not null
Rules are not rechecked in the body of any instance, and the template
passes the lying rule as well. The second bullet
handles a similar case involving formal functions. The rules are rule
so complex because they have it
to apply to formals used in bodies of child generics as well
as in the bodies of generics.
if S is an elementary
Q shall be
a constant other than a dereference of an access type; or
the nominal subtype
of Q shall be statically compatible with S; or
S shall statically
match the base subtype of its type if scalar, or the first subtype of
its type if an access type.
if S is a composite
subtype, then Q shall be known to be constrained or S shall
statically match the first subtype of its type.
no restriction if the expression
is a value.
Reason: This check
prevents the renamed object from violating its nominal subtype. As the
subtype is only checked when the object is renamed, we make it illegal
if the actual object is a variable whose value could be changed afterwards
to violate the subtype. This is messy as “known to be constrained”
is only defined for composite objects, so we have to handle elementary
objects and all values separately.
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.
In addition to the places where
Legality Rules normally apply (see 12.3),
these rules also apply in the private part of an instance of a generic
applies to all of the Legality Rules in this subclause. Rechecks are
needed for most of the rules (but not the first two).
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” requirement on generics is
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 := 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?
In addition, the “known to be constrained” rules include
assume-the-worst rules for generic bodies partially to prevent such problems.
Note that if an
implementation chooses to deallocate-then-reallocate on assignment_statement
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
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
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.
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.
Incompatibilities With Ada 95
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:
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
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).
Wording Changes from Ada 95
Fixed to forbid renamings of depends-on-discriminant
components if the type might
Incompatibilities With Ada 2005
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
Incompatibilities With Ada 2012
Correction: The Legality
Rules for renames with null exclusions no longer applies to generic formal
objects of mode in, but does apply to renames of generic formal
functions. This means a few unlikely programs are now illegal that were
previously allowed by original Ada 2012, while more programs that were
previously llegal will be allowed.
Correction: Added a rule to ensure that
a renaming of a qualified_expression
of a variable is allowed only if the variable will always remain within
the nominal subtype of the qualified_expression.
This was not required in Ada 2012. Renamings that are now illegal are
at risk of causing erroneous execution if the variable value is changed
to a bad value; this is consistent with other rules preventing renamings
from changing to violate their known properties.
Extensions to Ada 2012
in an object renaming is now optional, as the subtype information it
provides is not trustworthy anyway (that comes from the renamed object
and there is no requirement that it is the same as that of the object).
An object renaming can now rename values, such
as named numbers. The renamed entity still has to be a name,
but an arbitrary expression
can be renamed by qualifying it.
Ada 2005 and 2012 Editions sponsored in part by Ada-Europe