8.5 Renaming Declarations
This Reference Manual output has not been verified, and may contain omissions or errors. Report any problems on the tracking issue
[A renaming_declaration declares another name for an entity, such as an object, exception, package, subprogram, entry, or generic unit. Alternatively, a subprogram_renaming_declaration can be the completion of a previous subprogram_declaration.]
Term entry: renaming — declaration that does not define a new entity, but instead defines a new view of an existing entity
Syntax
2renaming_declaration ::=
object_renaming_declaration
| exception_renaming_declaration
| package_renaming_declaration
| subprogram_renaming_declaration
| generic_renaming_declaration
Dynamic Semantics
3The elaboration of a renaming_declaration evaluates the name that follows the reserved word renames and thereby determines the view and entity denoted by this name (the renamed view and renamed entity). [A name that denotes the renaming_declaration denotes (a new view of) the renamed entity.]
NOTE 1 Renaming can be used to resolve name conflicts and to act as a shorthand. Renaming with a different identifier or operator_symbol does not hide the old name; the new name and the old name can be visible at different places.
NOTE 2 A subtype defined without any additional constraint can be used to achieve the effect of renaming another subtype (including a task or protected subtype) as in
subtype Mode is Ada.Text_IO.File_Mode;
Wording Changes from Ada 83
The second sentence of RM83-8.5(3), “At any point where a renaming declaration is visible, the identifier, or operator symbol of this declaration denotes the renamed entity.” is incorrect. It doesn't say directly visible. Also, such an identifier might resolve to something else.
The verbiage about renamings being legal “only if exactly one...”, which appears in RM83-8.5(4) (for objects) and RM83-8.5(7) (for subprograms) is removed, because it follows from the normal rules about overload resolution. For language lawyers, these facts are obvious; for programmers, they are irrelevant, since failing these tests is highly unlikely.
8.5.1 Object Renaming Declarations
1/5[An object_renaming_declaration is used to rename an object or value.]
Syntax
2/5object_renaming_declaration ::=
defining_identifier [: [null_exclusion] subtype_mark] renames object_name
[aspect_specification];
| defining_identifier : access_definition renames object_name
[aspect_specification];
Name Resolution Rules
3/5The type of the object_name shall resolve to the type determined by the subtype_mark, if present. If no subtype_mark or access_definition is present, the expected type of the object_name is any type.
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 the access_definition.
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:
X: T;
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. in out.
Legality Rules
4/5The renamed entity shall be an object or value.
In the case where the type is defined by an access_definition, the type of the renamed entity and the type defined by the access_definition:
- 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 profiles.
For an object_renaming_declaration with a null_exclusion or an access_definition that has a null_exclusion, the subtype of the object_name shall exclude null. In addition, if the object_renaming_declaration occurs within the body of a generic unit G or within the body of a generic unit declared within the declarative region of generic unit G, then:
- if the object_
namestatically denotes a generic formal object of mode in out of G, then the declaration of that object shall have anull_exclusion; 4.6/5 - if the object_
namestatically denotes a call of a generic formal function of G, then the declaration of the result of that function shall have anull_exclusion.
These rules prevent “lying”. Null must never be the value of an object with an explicit null_exclusion. The bullets are assume-the-worst rules that prevent trouble in two obscure cases:
type Acc_I is access Integer;
subtype Acc_NN_I is not null Acc_I;
Obj : Acc_I := null;
4.c/2
generic
B : in out Acc_NN_I;
package Gen is
...
end Gen;
4.d/2
package body Gen is
D : not null Acc_I renames B;
end Gen;
4.e/2
package Inst is new Gen (B => Obj);
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 so complex because they have to apply to formals used in bodies of child generics as well as in the bodies of generics.
In the case where the object_name is a qualified_expression with a nominal subtype S and whose expression is a name that denotes an object Q:
- if S is an elementary subtype, then:
- 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.
There's no restriction if the expression is a value.
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.
{8652/0017} 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 (see 12.3), these rules also apply in the private part of an instance of a generic unit.
This applies to all of the Legality Rules in this subclause. Rechecks are needed for most of the rules (but not the first two).
This prevents renaming of subcomponents that might disappear, which might leave dangling references. Similar restrictions exist for the Access attribute.
{8652/0017} 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
record
case D1 is
when False =>
C1 : Integer;
when True =>
null;
end case;
end record;
5.a.3/1
generic
type F is new T1;
X : in out F;
package G is
C1_Ren : Integer renames X.C1;
end G;
5.a.4/1
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_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.
If it is a generic formal object, then the assume-the-best or assume-the-worst rules are applied as appropriate.
Static Semantics
6/5An object_renaming_declaration declares a new view [of the renamed entity] whose properties are identical to those of the renamed view. [Thus, the properties of the renamed entity are not affected by the renaming_declaration. In particular, its nominal subtype, whether it is a value or an object, its value if it is an object, and whether or not it is a constant, are unaffected; similarly, the constraints and other properties of its nominal subtype are not affected by renaming (any constraint implied by the subtype_mark or access_definition of the object_renaming_declaration is ignored).]
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.
Examples
7Example of renaming an object:
declare
L : Person renames Leftmost_Person; -- see 3.10.1
begin
L.Age := L.Age + 1;
end;
Example of renaming a value:
Uno renames One; -- see 3.3.2
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).
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.
Wording Changes from Ada 95
{8652/0017} Corrigendum: Fixed to forbid renamings of depends-on-discriminant components if the type might be definite.
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
An optional aspect_specification can be used in an object_renaming_declaration. This is described in 13.1.1.
Incompatibilities With Ada 2012
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.
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
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).
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.
8.5.2 Exception Renaming Declarations
1[An exception_renaming_declaration is used to rename an exception.]
Syntax
2/3exception_renaming_declaration ::=
defining_identifier : exception renames exception_name
[aspect_specification];
Legality Rules
3The renamed entity shall be an exception.
Static Semantics
4An exception_renaming_declaration declares a new view [of the renamed exception].
Examples
5Example of renaming an exception:
EOF : exception renames Ada.IO_Exceptions.End_Error; -- see A.13
Extensions to Ada 2005
An optional aspect_specification can be used in an exception_renaming_declaration. This is described in 13.1.1.
8.5.3 Package Renaming Declarations
1[A package_renaming_declaration is used to rename a package.]
Syntax
2/3package_renaming_declaration ::=
package defining_program_unit_name renames package_name
[aspect_specification];
Legality Rules
3The renamed entity shall be a package.
If the package_name of a package_renaming_declaration denotes a limited view of a package P, then a name that denotes the package_renaming_declaration shall occur only within the immediate scope of the renaming or the scope of a with_clause that mentions the package P or, if P is a nested package, the innermost library package enclosing P.
The use of a renaming that designates a limited view is restricted to locations where we know whether the view is limited or nonlimited (based on a with_clause). We don't want to make an implicit limited view, as those are not transitive like a regular view. Implementations should be able to see all limited views needed based on the context_clause.
Static Semantics
4A package_renaming_declaration declares a new view [of the renamed package].
[At places where the declaration of the limited view of the renamed package is visible, a name that denotes the package_renaming_declaration denotes a limited view of the package (see 10.1.1).]
This rule is found in 8.3, “Visibility”.
Examples
5Example of renaming a package:
package TM renames Table_Manager;
Wording Changes from Ada 95
Uses of renamed limited views of packages can only be used within the scope of a with_clause for the renamed package.
Extensions to Ada 2005
An optional aspect_specification can be used in a package_renaming_declaration. This is described in 13.1.1.
8.5.4 Subprogram Renaming Declarations
1/3A subprogram_renaming_declaration can serve as the completion of a subprogram_declaration; such a renaming_declaration is called a renaming-as-body. A subprogram_renaming_declaration that is not a completion is called a renaming-as-declaration[, and is used to rename a subprogram (possibly an enumeration literal) or an entry].
Syntax
2/3subprogram_renaming_declaration ::=
[overriding_indicator]
subprogram_specification renames callable_entity_name
[aspect_specification];
Name Resolution Rules
3The expected profile for the callable_entity_name is the profile given in the subprogram_specification.
Legality Rules
4/5The profile of a renaming-as-declaration shall be mode conformant with that of the renamed callable entity.
For a parameter or result subtype of the subprogram_specification that has an explicit null_exclusion:
- if the callable_entity_
namestatically denotes a generic formal subprogram of a generic unit G, and thesubprogram_renaming_declarationoccurs within the body of a generic unit G or within the body of a generic unit declared within the declarative region of the generic unit G, then the corresponding parameter or result subtype of the formal subprogram of G shall have anull_exclusion; 4.3/2 - otherwise, the subtype of the corresponding parameter or result type of the renamed callable entity 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.
This rule prevents “lying”. Null must never be the value of a parameter or result with an explicit null_exclusion. The first bullet is an assume-the-worst rule which prevents trouble in generic bodies (including bodies of child units) when the formal subtype excludes null implicitly.
{8652/0027} {8652/0028} The profile of a renaming-as-body shall conform fully to that of the declaration it completes. If the renaming-as-body completes that declaration before the subprogram it declares is frozen, the profile shall be mode conformant with that of the renamed callable entity and the subprogram it declares takes its convention from the renamed subprogram; otherwise, the profile shall be subtype conformant with that of the renamed callable entity and the convention of the renamed subprogram shall not be Intrinsic. A renaming-as-body is illegal if the declaration occurs before the subprogram whose declaration it completes is frozen, and the renaming renames the subprogram itself, through one or more subprogram renaming declarations, none of whose subprograms has been frozen.
The otherwise part of the second sentence is to allow an implementation of a renaming-as-body as a single jump instruction to the target subprogram. Among other things, this prevents a subprogram from being completed with a renaming of an entry. (In most cases, the target of the jump can be filled in at link time. In some cases, such as a renaming of a name like "A(I).all", an indirect jump is needed. Note that the name is evaluated at renaming time, not at call time.)
{8652/0028} The first part of the second sentence is intended to allow renaming-as-body of predefined operators before the subprogram_declaration is frozen. For some types (such as integer types), the parameter type for operators is the base type, and it would be very strange for
function Equal (A, B : in T) return Boolean;
function Equal (A, B : in T) return Boolean renames "=";
to be illegal. (Note that predefined operators cannot be renamed this way after the subprogram_declaration is frozen, as they have convention Intrinsic.)
The first sentence is the normal rule for completions of subprogram_declarations.
An entry_declaration, unlike a subprogram_declaration, cannot be completed with a renaming_declaration. Nor can a generic_subprogram_declaration.
The syntax rules prevent a protected subprogram declaration from being completed by a renaming. This is fortunate, because it allows us to avoid worrying about whether the implicit protected object parameter of a protected operation is involved in the conformance rules.
{8652/0027} Circular renames before freezing is illegal, as the compiler would not be able to determine the convention of the subprogram. Other circular renames are handled below; see Bounded (Run-Time) Errors.
The callable_entity_name of a renaming shall not denote a subprogram that requires overriding (see 3.9.3).
Such a rename cannot be of the inherited subprogram (which requires overriding because it cannot be called), and thus cannot squirrel away a subprogram (see below). That would be confusing, so we make it illegal. The renaming is allowed after the overriding, as then the name will denote the overriding subprogram, not the inherited one.
The callable_entity_name of a renaming-as-body shall not denote an abstract subprogram.
If the callable_entity_name of a renaming is a prefixed view, the prefix of that view shall denote an object for which renaming is allowed.
The prefix in such a case is essentially renamed and passed to any calls of the renamed subprogram. If the prefix isn't legal to rename, that doesn't make sense (and allowing it might end up passing a nonexistent object to some calls).
A name that denotes a formal parameter of the subprogram_specification is not allowed within the callable_entity_name.
This is to prevent things like this:
function F(X : Integer) return Integer renames Table(X).all;
function F(X : Integer; Y : Integer := X) return Integer;
Static Semantics
7A renaming-as-declaration declares a new view of the renamed entity. The profile of this new view takes its subtypes, parameter modes, and calling convention from the original profile of the callable entity, while taking the formal parameter names and default_expressions from the profile given in the subprogram_renaming_declaration. The new view is a function or procedure, never an entry.
To be honest: When renaming an entry as a procedure, the compile-time rules apply as if the new view is a procedure, but the run-time semantics of a call are that of an entry call.
For example, it is illegal for the entry_call_statement of a timed_entry_call to call the new view. But what looks like a procedure call will do things like barrier waiting.
{8652/0105} All properties of the renamed entity are inherited by the new view unless otherwise stated by this document. In particular, if the renamed entity is abstract, the new view also is abstract. Similarly, if the renamed entity is not a program unit, then neither is the renaming. (Implicitly declared subprograms are not program units, see 10.1).
Dynamic Semantics
7.1/1{8652/0014} For a call to a subprogram whose body is given as a renaming-as-body, the execution of the renaming-as-body is equivalent to the execution of a subprogram_body that simply calls the renamed subprogram with its formal parameters as the actual parameters and, if it is a function, returns the value of the call.
This implies that the subprogram completed by the renaming-as-body has its own elaboration check.
For a call on a renaming of a dispatching subprogram that is overridden, if the overriding occurred before the renaming, then the body executed is that of the overriding declaration, even if the overriding declaration is not visible at the place of the renaming; otherwise, the inherited or predefined subprogram is called. A corresponding rule applies to a call on a renaming of a predefined equality operator for an untagged record type.
Note that whether or not the renaming is itself primitive has nothing to do with the renamed subprogram.
Consider the following example:
package P is
type T is tagged null record;
function Predefined_Equal(X, Y : T) return Boolean renames "=";
private
function "="(X, Y : T) return Boolean; -- Override predefined "=".
end P;
8.e
with P; use P;
package Q is
function User_Defined_Equal(X, Y : T) return Boolean renames P."=";
end Q;
A call on Predefined_Equal will execute the predefined equality operator of T, whereas a call on User_Defined_Equal will execute the body of the overriding declaration in the private part of P.
Thus a renaming allows one to squirrel away a copy of an inherited or predefined subprogram before later overriding it.
Bounded (Run-Time) Errors
8.1/1{8652/0027} If a subprogram directly or indirectly renames itself, then it is a bounded error to call that subprogram. Possible consequences are that Program_Error or Storage_Error is raised, or that the call results in infinite recursion.
{8652/0027} This has to be a bounded error, as it is possible for a renaming-as-body appearing in a package body to cause this problem. Thus it is not possible in general to detect this problem at compile time.
NOTE 1 A procedure can only be renamed as a procedure. A function whose defining_designator is either an identifier or an operator_symbol can be renamed with either an identifier or an operator_symbol; for renaming as an operator, the subprogram specification given in the renaming_declaration is subject to the rules given in 6.6 for operator declarations. Enumeration literals can be renamed as functions; similarly, attribute_references that denote functions (such as references to Succ and Pred) can be renamed as functions. An entry can only be renamed as a procedure; the new name is only allowed to appear in contexts that allow a procedure name. An entry of a family can be renamed, but an entry family cannot be renamed as a whole.
NOTE 2 The operators of the root numeric types cannot be renamed because the types in the profile are anonymous, so the corresponding specifications cannot be written; the same holds for certain attributes, such as Pos.
NOTE 3 The primitiveness of a renaming-as-declaration is determined by its profile, and by where it occurs, as for any declaration of (a view of) a subprogram; primitiveness is not determined by the renamed view. In order to perform a dispatching call, the subprogram name has to denote a primitive subprogram, not a nonprimitive renaming of a primitive subprogram.
A subprogram_renaming_declaration could more properly be called renaming_as_subprogram_declaration, since you're renaming something as a subprogram, but you're not necessarily renaming a subprogram. But that's too much of a mouthful. Or, alternatively, we could call it a callable_entity_renaming_declaration, but that's even worse. Not only is it a mouthful, it emphasizes the entity being renamed, rather than the new view, which we think is a bad idea. We'll live with the oddity.
Examples
13Examples of subprogram renaming declarations:
procedure My_Write(C : in Character) renames Pool(K).Write; -- see 4.1.3
15
function Real_Plus(Left, Right : Real ) return Real renames "+";
function Int_Plus (Left, Right : Integer) return Integer renames "+";
16
function Rouge return Color renames Red; -- see 3.5.1
function Rot return Color renames Red;
function Rosso return Color renames Rouge;
17
function Next(X : Color) return Color renames Color'Succ; -- see 3.5.1
Example of a subprogram renaming declaration with new parameter names:
function "*" (X,Y : Vector) return Real renames Dot_Product; -- see 6.1
Example of a subprogram renaming declaration with a new default expression:
function Minimum(L : Link := Head) return Cell renames Min_Cell; -- see 6.1
Extensions to Ada 95
{8652/0028} Corrigendum: Allowed a renaming-as-body to be just mode conformant with the specification if the subprogram is not yet frozen.
Wording Changes from Ada 95
{8652/0014} Corrigendum: Described the semantics of renaming-as-body, so that the location of elaboration checks is clear.
{8652/0027} Corrigendum: Clarified that circular renaming-as-body is illegal (if it can be detected in time) or a bounded error.
Amendment Clarified that renaming a shall-be-overridden subprogram is illegal, as well as renaming-as-body an abstract subprogram.
Inconsistencies With Ada 2005
Renaming of user-defined untagged record equality is now defined to call the overridden body so long as the overriding occurred before the renames. This could change the body called in unusual cases; the change is necessary to preserve the principle that the body called for an explicit call to "=" (via a renames in this case) is the same as the one inherited for a derived type and used in generics. Note that any renamings before the overriding will be unchanged. Any differences caused by the change will be rare and most likely will fix a bug.
Extensions to Ada 2005
An optional aspect_specification can be used in a subprogram_renaming_declaration. This is described in 13.1.1.
Incompatibilities With Ada 2012
Added a rule to ensure that the prefix of a renaming of a prefixed view continues to exist during the life of a renames. If the prefix is a subcomponent that depends on discriminants, Ada 2005 and 2012 would have allowed the prefix while Ada 2022 would not. Without this change, explicit forms (renaming the object and then using that in calls) would be safer than the renaming; that's inconsistent with other kinds of renaming.
Wording Changes from Ada 2012
Added wording to ensure that the object subject to a Legality Rule can be determined at compile-time. The alternative being nonsense, we treat this as a wording change.
8.5.5 Generic Renaming Declarations
1[A generic_renaming_declaration is used to rename a generic unit.]
Syntax
2/3generic_renaming_declaration ::=
generic package defining_program_unit_name renames generic_package_name
[aspect_specification];
| generic procedure defining_program_unit_name renames generic_procedure_name
[aspect_specification];
| generic function defining_program_unit_name renames generic_function_name
[aspect_specification];
Legality Rules
3The renamed entity shall be a generic unit of the corresponding kind.
Static Semantics
4A generic_renaming_declaration declares a new view [of the renamed generic unit].
NOTE Although the properties of the new view are the same as those of the renamed view, the place where the generic_renaming_declaration occurs can affect the legality of subsequent renamings and instantiations that denote the generic_renaming_declaration, in particular if the renamed generic unit is a library unit (see 10.1.1).
Examples
6Example of renaming a generic unit:
generic package Enum_IO renames Ada.Text_IO.Enumeration_IO; -- see A.10.10
Extensions to Ada 83
Renaming of generic units is new to Ada 95. It is particularly important for renaming child library units that are generic units. For example, it might be used to rename Numerics.Generic_Elementary_Functions as simply Generic_Elementary_Functions, to match the name for the corresponding Ada-83-based package.
Wording Changes from Ada 83
Extensions to Ada 2005
An optional aspect_specification can be used in a generic_renaming_declaration. This is described in 13.1.1.