12.4 Formal Objects
[
A generic
formal object can be used to pass a value or variable to a generic unit.]
Language Design Principles
Syntax
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
mode
in, the expected type for the actual is the type of the formal.
{
AI95-00423-01}
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.
Legality Rules
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, 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).
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.)
{
AI95-00423-01}
shall both be access-to-object types with statically matching designated
subtypes and with both or neither being access-to-constant types; or
{
AI95-00423-01}
shall both be access-to-subprogram types with subtype conformant designated
profiles.
Reason: {
AI95-00287-01}
{
AI95-00423-01}
{
AI12-0287-1}
This rule prevents “lying”.
Null must never be the
value of an object with an explicit
null_exclusion.
The “in addition” part is an assume-the-worst rule which
prevents trouble in generic bodies (including bodies of child units)
when the subtype of the formal object of mode
in out excludes
null implicitly. Since a generic formal object of mode
in is like
a constant initialized to the value of the actual, the runtime check
performed by the initialization is enough to prevent lying; thus we don't
need a Legality Rule for such objects.
Static Semantics
Reason: {
AI95-00255-01}
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 object.
Discussion: {
AI95-00423-01}
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
type.
{
AI95-00269-01}
In an instance,
a
formal_object_declaration
of mode
in is a
full constant declaration and 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.
Ramification: {
AI95-00287-01}
These rules imply that generic formal objects of mode
in are passed
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
in out is the subtype of the corresponding generic actual.
Dynamic Semantics
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.
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.
NOTE 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
are defined.
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
{
AI95-00255-01}
Clarified that the nominal subtype of a composite formal
in out
object is unconstrained if the first subtype of the type is unconstrained.
{
AI95-00269-01}
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
Extensions to Ada 2012
{
AI12-0287-1}
Correction: The Legality Rule for matching
null exclusions only applies to formal objects with mode
in out.
(
In mode formal objects have a run-time check to avoid problems.)
This is an extension as some instantiations that were illegal in original
Ada 2012 are now legal.
Ada 2005 and 2012 Editions sponsored in part by Ada-Europe
