12.4 Formal Objects
This Reference Manual output has not been verified, and may contain omissions or errors. Report any problems on the tracking issue
[ A generic formal object can be used to pass a value or variable to a generic unit.]
Language Design Principles
explicit_generic_actual_parameter
.explicit_generic_actual_parameter
. Syntax
2/3formal_object_declaration
::=
defining_identifier_list
: mode
[null_exclusion
] subtype_mark
[:= default_expression
]
[aspect_specification
];
| defining_identifier_list
: mode
access_definition
[:= default_expression
]
[aspect_specification
];
Name Resolution Rules
3The 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.
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
.
object_renaming_declaration
s for a discussion of the reason for this rule. Legality Rules
6If 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.
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).
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.) 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:
- shall both be access-to-object types with statically matching designated subtypes and with both or neither being access-to-constant types; or
- shall both be access-to-subprogram types with subtype conformant designated profiles.
For a formal_object_declaration
of mode in out with a null_exclusion
or an access_definition
that has a null_exclusion
, the subtype of the actual matching the formal_object_declaration
shall exclude null. In addition, if the actual matching the formal_object_declaration
statically denotes the generic formal object of mode in out 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
. 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 unit.
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
9/2A formal_object_declaration
declares a generic formal object. The default mode is in. For a formal object of mode in, the nominal subtype is the one denoted by the subtype_mark
or access_definition
in the declaration of the formal. For a formal object of mode in out, its type is determined by the subtype_mark
or access_definition
in the declaration; its nominal subtype is nonstatic, even if the subtype_mark
denotes a static subtype; for a composite type, its nominal subtype is unconstrained if the first subtype of the type is unconstrained[, even if the subtype_mark
denotes a constrained subtype].
access_definition
s; an access subtype can neither be a static subtype nor be a composite type. 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.
formal_object_declaration
of mode in as for any constant; see 3.3.1, “Object Declarations” and 7.6, “Assignment and Finalization”.Dynamic Semantics
11For 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].
generic_association
for a formal object of mode in out is covered by the general Dynamic Semantics rule in 12.3. 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. Extensions to Ada 83
Wording Changes from Ada 83
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.Extensions to Ada 95
function_call
or aggregate
, see 7.5.Wording Changes from Ada 95
Extensions to Ada 2005
aspect_specification
can be used in a formal_object_declaration
. This is described in 13.1.1.