Contents Index Search Previous Next
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.
Contents Index Search Previous Next Legal