12.4 Formal Objects
formal object can be used to pass a value or variable to a generic unit.]
Language Design Principles
Name Resolution Rules
The expected type for the default_expression
if any, of a formal object is the type of the formal object.
For a generic formal object of
, the expected type for the actual is the type of the formal.
For a generic formal object of mode in out
, the type of the actual
shall resolve to the type determined by the subtype_mark,
or for a formal_object_declaration
with an access_definition,
to a specific anonymous access type. If the anonymous access type is
an access-to-object type, the type of the actual 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 actual shall have a designated profile which is type conformant
with that of the access_definition.
of the formal.
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
Ramification: Mode out is not
allowed for generic formal objects.
For a generic formal object of mode in
actual shall be an expression
For a generic formal object of mode in out
, the actual shall be
denotes a variable for which renaming is allowed (see 8.5.1
To be honest:
The part of this that requires
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
a Name Resolution Rule.)
In the case where
the type of the formal is defined by an access_definition,
the type of the actual and the type of the formal: The
type of a generic formal object of mode in shall be nonlimited.
shall both be access-to-object types with statically
matching designated subtypes and with both or neither being access-to-constant
shall both be access-to-subprogram types with subtype
conformant designated profiles.
if the actual matching the
denotes the generic formal object of another generic unit G, and
the instantiation containing the actual occurs within the body of G
or within the body of a generic unit declared within the declarative
region of G, then the declaration of the formal object of G
shall have a null_exclusion;
otherwise, the subtype of
the actual matching the formal_object_declaration
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
This rule prevents “lying”. Null
must never be the value of an object 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 subtype of
the formal object excludes null implicitly. 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.
We require that the subtype is unconstrained because
a formal in out acts like a renaming, and thus the given subtype
is ignored for purposes of matching; any value of the type can be passed.
Thus we can assume only that the object is constrained if the first subtype
is constrained (and thus there can be no unconstrained subtypes for the
type). If we didn't do this, it would be possible to rename or take 'Access
of components that could disappear due to an assignment to the whole
The two “even if” clauses are OK even
though they don't mention access_definitions;
an access subtype can neither be a static subtype nor be a composite
an instance, a formal_object_declaration
of mode in is a full constant declaration
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.
These rules imply that generic formal objects of mode in
by copy (or are built-in-place for a limited type)
whereas generic formal objects of mode in out
are passed by reference.
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
is the subtype of the corresponding generic actual.
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
Ramification: This includes evaluating
the actual and doing a subtype conversion, which might raise an exception.
The rule for evaluating a
for a formal object of mode in out
is covered by the general Dynamic
Semantics rule in 12.3
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.
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
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
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
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.
Extensions to Ada 95
Wording Changes from Ada 95
Clarified that the nominal subtype of a composite
formal in out object is unconstrained if the first subtype of
the type is unconstrained.
Clarified that a formal in object can be
static when referenced from outside of the instance (by declaring such
an object to be a full constant declaration).
Extensions to Ada 2005
Ada 2005 and 2012 Editions sponsored in part by Ada-Europe