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: {AI12-0287-1} {AI12-0005-1} These rules prevent This rule prevents “lying”. Null 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 trouble in two one obscure cases case:

{AI12-0287-1} 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 second bullet handles a similar case involving formal functions. The rules are rule is so complex because they have it has to apply to formals used in bodies of child generics as well as in the bodies of generics. 

Ramification: There's 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. 

Discussion: This 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.

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

{AI05-0008-1} In addition, the “known to be constrained” rules include assume-the-worst rules for generic bodies partially to prevent such problems.

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. 

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} 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} 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).

{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 if 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. 

{AI05-0008-1} Correction: 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.

{AI05-0183-1} An optional aspect_specification can be used in an object_renaming_declaration. This is described in 13.1.1. 

{AI12-0287-1} 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.

{AI12-0401-1} 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. 

{AI12-0275-1} The subtype_mark 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).

{AI12-0383-1} 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.