Parameter Associations

[{parameter passing} A parameter association defines the association between an actual parameter and a formal parameter.]

Language Design Principles

The parameter passing rules for out parameters are designed to ensure that the parts of a type that have implicit initial values (see 3.3.1) don't become “de-initialized” by being passed as an out parameter.

Name Resolution Rules

The formal_parameter_selector_name of a parameter_association shall resolve to denote a parameter_specification of the view being called.

{actual parameter (for a formal parameter)} The actual parameter is either the explicit_actual_parameter given in a parameter_association for a given formal parameter, or the corresponding default_expression if no parameter_association is given for the formal parameter. {expected type (actual parameter)} The expected type for an actual parameter is the type of the corresponding formal parameter.

To be honest: The corresponding default_expression is the one of the corresponding formal parameter in the profile of the view denoted by the name or prefix of the call.

If the mode is in, the actual is interpreted as an expression; otherwise, the actual is interpreted only as a name, if possible.

Ramification: This formally resolves the ambiguity present in the syntax rule for explicit_actual_parameter. Note that we don't actually require that the actual be a name if the mode is not in; we do that below.

Legality Rules

If the mode is in out or out, the actual shall be a name that denotes a variable.

Discussion: We no longer need “or a type_conversion whose argument is the name of a variable,” because a type_conversion is now a name, and a type_conversion of a variable is a variable.

Reason: The requirement that the actual be a (variable) name is not an overload resolution rule, since we don't want the difference between expression and name to be used to resolve overloading. For example:

procedure Print(X : in Integer; Y : in Boolean := True);
procedure Print(Z : in out Integer);
. . .
Print(3); -- Ambiguous!

The above call to Print is ambiguous even though the call is not compatible with the second Print which requires an actual that is a (variable) name (“3” is an expression, not a name). This requirement is a legality rule, so overload resolution fails before it is considered, meaning that the call is ambiguous.

The type of the actual parameter associated with an access parameter shall be convertible (see 4.6) to its anonymous access type. {convertible (required) [partial]}

Dynamic Semantics

{evaluation (parameter_association) [partial]} For the evaluation of a parameter_association:

For a parameter [(of any mode)] that is passed by reference (see 6.2), a view conversion of the actual parameter to the nominal subtype of the formal parameter is evaluated, and the formal parameter denotes that conversion. {implicit subtype conversion (parameter passing) [partial]}

{assignment operation (during evaluation of a parameter_association)} For an in or in out parameter that is passed by copy (see 6.2), the formal parameter object is created, and the value of the actual parameter is converted to the nominal subtype of the formal parameter and assigned to the formal. {implicit subtype conversion (parameter passing) [partial]}

For an access type, the formal parameter is initialized from the value of the actual, without a constraint check;

Reason: This preserves the Language Design Principle that an object of an access type is always initialized with a “reasonable” value.

For a composite type with discriminants or that has implicit initial values for any subcomponents (see 3.3.1), the behavior is as for an in out parameter passed by copy.

Reason: This ensures that no part of an object of such a type can become “de-initialized” by being part of an out parameter.

Ramification: This includes an array type whose component type is an access type, and a record type with a component that has a default_expression, among other things.

For any other type, the formal parameter is uninitialized. If composite, a view conversion of the actual parameter to the nominal subtype of the formal is evaluated [(which might raise Constraint_Error)], and the actual subtype of the formal is that of the view conversion. If elementary, the actual subtype of the formal is given by its nominal subtype.

Ramification: This case covers scalar types, and composite types whose subcomponent's subtypes do not have any implicit initial values. The view conversion for composite types ensures that if the lengths don't match between an actual and a formal array parameter, the Constraint_Error is raised before the call, rather than after.

{constrained (object) [partial]} {unconstrained (object) [partial]} A formal parameter of mode in out or out with discriminants is constrained if either its nominal subtype or the actual parameter is constrained.

{parameter copy back} {copy back of parameters} {parameter assigning back} {assigning back of parameters} {assignment operation (during parameter copy back)} After normal completion and leaving of a subprogram, for each in out or out parameter that is passed by copy, the value of the formal parameter is converted to the subtype of the variable given as the actual parameter and assigned to it. {implicit subtype conversion (parameter passing) [partial]} These conversions and assignments occur in an arbitrary order.

Ramification: The conversions mentioned above during parameter passing might raise Constraint_Error — (see 4.6).

Ramification: If any conversion or assignment as part of parameter passing propagates an exception, the exception is raised at the place of the subprogram call; that is, it cannot be handled inside the subprogram_body.

Proof: Since these checks happen before or after executing the subprogram_body, the execution of the subprogram_body does not dynamically enclose them, so it can't handle the exceptions.

Discussion: The variable we're talking about is the one denoted by the variable_name given as the explicit_actual_parameter. If this variable_name is a type_conversion, then the rules in 4.6 for assigning to a view conversion apply. That is, if X is of subtype S1, and the actual is S2(X), the above-mentioned conversion will convert to S2, and the one mentioned in 4.6 will convert to S1.

Extensions to Ada 83

{extensions to Ada 83} In Ada 95, a program can rely on the fact that passing an object as an out parameter does not “de-initialize” any parts of the object whose subtypes have implicit initial values. (This generalizes the RM83 rule that required copy-in for parts that were discriminants or of an access type.)

Wording Changes from Ada 83

We have eliminated the subclause on Default Parameters, as it is subsumed by earlier clauses and subclauses.