6.4.1 Parameter Associations
1
[
{parameter passing}
A parameter association defines the association between
an actual parameter and a formal parameter.]
Language Design Principles
1.a
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
2
The formal_parameter_selector_name
of a parameter_association shall resolve to
denote a parameter_specification of the view
being called.
3
{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.
3.a
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.
4
If the mode is in, the actual is interpreted
as an expression; otherwise, the actual is
interpreted only as a name, if possible.
4.a
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
5
If the mode is in out or out, the actual
shall be a name that denotes a variable.
5.a
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.
5.b
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:
5.c
procedure Print(X : in Integer; Y : in Boolean := True);
procedure Print(Z : in out Integer);
. . .
Print(3); -- Ambiguous!
5.d
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.
6
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
7
{evaluation
(parameter_association) [partial]} For
the evaluation of a
parameter_association:
8
- The actual parameter is first evaluated.
9
- For an access parameter, the access_definition
is elaborated, which creates the anonymous access type.
10
- 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]}
10.a
Discussion: We are always allowing sliding,
even for [in[ out by-reference parameters.
11
- {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]}
11.a
Ramification: The conversion mentioned
here is a value conversion.
12
- For
an out parameter that is passed by copy, the formal parameter
object is created, and:
13
- For an access type, the
formal parameter is initialized from the value of the actual, without
a constraint check;
13.a
Reason: This preserves the Language Design
Principle that an object of an access type is always initialized with
a “reasonable” value.
14
- 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.
14.a
Reason: This ensures that no part of
an object of such a type can become “de-initialized” by being
part of an out parameter.
14.b
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.
15
- 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.
15.a
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.
16
{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.
17
{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.
17.a
Ramification: The conversions mentioned
above during parameter passing might raise Constraint_Error — (see
4.6).
17.b
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.
17.c
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.
17.d
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
17.e
{
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
17.f
We have eliminated the subclause on Default
Parameters, as it is subsumed by earlier clauses and subclauses.
Sponsored by Ada-Europe