Contents Index Previous Next
12.4 Formal Objects
1
[
{generic formal object}
{formal object, generic}
A generic formal object can be used to pass a value
or variable to a generic unit.]
Language Design Principles
1.a
A generic formal object of mode
in is like a constant initialized to the value of the explicit_generic_actual_parameter.
1.b
A generic formal object of mode
in out is like a renaming of the explicit_generic_actual_parameter.
Syntax
2
formal_object_declaration
::=
defining_identifier_list :
mode subtype_mark [:=
default_expression];
Name Resolution Rules
3
{expected type (generic formal
object default_expression) [partial]} The
expected type for the
default_expression,
if any, of a formal object is the type of the formal object.
4
{expected type (generic formal
in object actual) [partial]} For a generic
formal object of mode
in, the expected type for the actual is
the type of the formal.
5
For a generic formal object of mode in out,
the type of the actual shall resolve to the type of the formal.
5.a
Reason: See the corresponding
rule for object_renaming_declarations
for a discussion of the reason for this rule.
Legality Rules
6
If a generic formal object has a default_expression,
then the mode shall be in [(either explicitly or by default)];
otherwise, its mode shall be either in or in out.
6.a
Ramification: Mode out
is not allowed for generic formal objects.
7
For a generic formal object of mode
in,
the actual shall be an
expression. For
a generic formal object of mode
in out, the actual shall be a
name
that denotes a variable for which renaming is allowed (see
8.5.1).
7.a
To be honest: The part
of this that requires an expression
or name is a Name Resolution Rule,
but that's too pedantic to worry about. (The part about denoting a variable,
and renaming being allowed, is most certainly not a Name Resolution
Rule.)
8
The type of a generic formal object of mode in
shall be nonlimited.
8.a
Reason: Since a generic
formal object is like a constant of mode in initialized to the
value of the actual, a limited type would not make sense, since initializing
a constant is not allowed for a limited type. That is, generic formal
objects of mode in are passed by copy, and limited types are not
supposed to be copied.
Static Semantics
9
A
formal_object_declaration
declares a generic formal object. The default mode is
in.
{nominal
subtype (of a generic formal object) [partial]} For
a formal object of mode
in, the nominal subtype is the one denoted
by the
subtype_mark in the declaration
of the formal.
{static (subtype) [partial]}
For a formal object of mode
in out, its type
is determined by the
subtype_mark
in the declaration; its nominal subtype is nonstatic, even if the
subtype_mark
denotes a static subtype.
10
{stand-alone constant (corresponding
to a formal object of mode in)} In an
instance, a
formal_object_declaration
of mode
in declares a new stand-alone constant object whose initialization
expression is the actual, whereas a
formal_object_declaration
of mode
in out declares a view whose properties are identical
to those of the actual.
10.a
Ramification: These rules
imply that generic formal objects of mode in are passed by copy,
whereas generic formal objects of mode in out are passed by reference.
10.b
10.c
{subtype (of a generic formal
object) [partial]} In an instance, the subtype
of a generic formal object of mode in is as for the equivalent
constant. In an instance, the subtype of a generic formal object of mode
in out is the subtype of the corresponding generic actual.
Dynamic Semantics
11
{evaluation (generic_association
for a formal object of mode in) [partial]} {assignment
operation (during evaluation of a generic_association for a formal object of
mode in)} For the evaluation of a
generic_association
for a formal object of mode
in, a constant object is created, the value
of the actual parameter is converted to the nominal subtype of the formal object,
and assigned to the object[, including any value adjustment -- see
7.6].
{implicit subtype conversion (generic formal object of mode
in) [partial]}
11.a
Ramification: This includes
evaluating the actual and doing a subtype conversion, which might raise
an exception.
11.b
Discussion: The rule for evaluating
a generic_association for a formal object
of mode in out is covered by the general Dynamic Semantics rule in 12.3.
12
6 The constraints that apply
to a generic formal object of mode in out are those of the corresponding
generic actual parameter (not those implied by the subtype_mark
that appears in the formal_object_declaration).
Therefore, to avoid confusion, it is recommended that the name of a first
subtype be used for the declaration of such a formal object.
12.a
Ramification: Constraint
checks are done at instantiation time for formal objects of mode in,
but not for formal objects of mode in out.
Extensions to Ada 83
12.b
{extensions to Ada 83}
In Ada 83, it is forbidden to pass a (nongeneric)
formal parameter of mode out, or a subcomponent thereof, to a
generic formal object of mode in out. This restriction is removed
in Ada 95.
Wording Changes from Ada 83
12.c
We make ``mode''
explicit in the syntax. RM83 refers to the mode without saying what it
is. This is also more uniform with the way (nongeneric) formal parameters
are defined.
12.d
We considered allowing mode out
in Ada 95, for uniformity with (nongeneric) formal parameters. The semantics
would be identical for modes in out and out. (Note that
generic formal objects of mode in out are passed by reference.
Note that for (nongeneric) formal parameters that are allowed to be passed
by reference, the semantics of in out and out is the same.
The difference might serve as documentation. The same would be true for
generic formal objects, if out were allowed, so it would be consistent.)
We decided not to make this change, because it does not produce any important
benefit, and any change has some cost.
Contents Index Previous Next Legal