8.5.1 Object Renaming Declarations

Reason: 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: 

When the above was legal, it was unclear whether Y was of type T or T'Class. Note that we still allow this: 

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.

Reason: This rule prevents “lying”. Null must never be the value of an object with an explicit null_exclusion. The first bullet is an assume-the-worst rule which prevents trouble in one obscure case: 

Without the first bullet rule, D would be legal, and contain the value null, because the rule about lying is satisfied for generic matching (Obj matches B; B does not explicitly state not null), Legality Rules are not rechecked in the body of any instance, and the template passes the lying rule as well. The rule is so complex because it has to apply to formals used in bodies of child generics as well as in the bodies of generics. 

Reason: This prevents renaming of subcomponents that might disappear, which might leave dangling references. Similar restrictions exist for the Access attribute.

{8652/0017} {AI95-00184-01} 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:

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. 

To be honest: {AI95-00363-01} If renamed entity is a subcomponent that depends on discriminants, and the subcomponent is a dereference of a general access type whose designated type is unconstrained and whose discriminants have defaults, the renaming is illegal. Such a general access type can designate an unconstrained (stack) object. Since such a type might not designate an object constrained by its initial value, the renaming is illegal — the rule says “is” constrained by its initial value, not “might be” constrained by its initial value. No other interpretation makes sense, as we can't have legality depending on something (which object is designated) that is not known at compile-time, and we surely can't allow this for unconstrained objects. The wording of the rule should be much clearer on this point, but this was discovered after the completion of Amendment 1 when it was too late to fix it. 

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.

{AI95-00409-01} 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. 

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. 

{AI95-00363-01} {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: 

{AI95-00230-01} {AI95-00231-01} {AI95-00254-01} {AI95-00409-01} {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 a component or stand-alone object).

{AI95-00231-01} {AI95-00423-01} A renaming can have a null_exclusion; if so, the renamed object must also exclude null, so that the null_exclusion does not lie. On the other hand, if the renaming does not have a null_exclusion. it excludes null of the renamed object does. 

{8652/0017} {AI95-00184-01} Corrigendum: Fixed to forbid renamings of depends-on-discriminant components if the type might be definite.