6 Subprograms
1 A subprogram is a program unit or intrinsic operation whose execution is
invoked by a subprogram call. There are two forms of subprogram: procedures
and functions. A procedure call is a statement; a function call is an
expression and returns a value. The definition of a subprogram can be given in
two parts: a subprogram declaration defining its interface, and a
subprogram_body defining its execution. [Operators and enumeration literals
are functions.]
1.a To be honest: A function call is an expression, but more
specifically it is a name.
1.b/2 Glossary entry: A subprogram is a section of a program that can be
executed in various contexts. It is invoked by a subprogram call
that may qualify the effect of the subprogram through the passing
of parameters. There are two forms of subprograms: functions,
which return values, and procedures, which do not.
1.c/2 Glossary entry: A function is a form of subprogram that returns a
result and can be called as part of an expression.
1.d/2 Glossary entry: A procedure is a form of subprogram that does not
return a result and can only be called by a statement.
2/3 {AI05-0299-1} A callable entity is a subprogram or entry (see Section 9).
A callable entity is invoked by a call; that is, a subprogram call or entry
call. A callable construct is a construct that defines the action of a call
upon a callable entity: a subprogram_body, entry_body, or accept_statement.
2.a Ramification: Note that "callable entity" includes predefined
operators, enumeration literals, and abstract subprograms. "
Call" includes calls of these things. They do not have callable
constructs, since they don't have completions.
6.1 Subprogram Declarations
1 [A subprogram_declaration declares a procedure or function.]
Syntax
2/3 {AI95-00218-03} {AI05-0183-1} subprogram_declaration ::=
[overriding_indicator]
subprogram_specification
[aspect_specification];
3/2 This paragraph was deleted.{AI95-00348-01}
4/2 {AI95-00348-01} subprogram_specification ::=
procedure_specification
| function_specification
4.1/2 {AI95-00348-01} procedure_specification ::=
procedure defining_program_unit_name parameter_profile
4.2/2 {AI95-00348-01} function_specification ::=
function defining_designator parameter_and_result_profile
5 designator ::= [parent_unit_name . ]identifier | operator_symbol
6 defining_designator ::= defining_program_unit_name
| defining_operator_symbol
7 defining_program_unit_name ::= [parent_unit_name
. ]defining_identifier
8 [The optional parent_unit_name is only allowed for library units (see
10.1.1).]
9 operator_symbol ::= string_literal
10/3 {AI95-00395-01} {AI05-0299-1} The sequence of characters in an
operator_symbol shall form a reserved word, a delimiter, or compound
delimiter that corresponds to an operator belonging to one of the six
categories of operators defined in subclause 4.5.
10.a/3 Reason: {AI95-00395-01} {AI05-0090-1} The "sequence of
characters" of the string literal of the operator is a technical term (see
2.6), and does not include the surrounding quote characters. As
defined in 2.2, lexical elements are "formed" from a sequence of
characters. Spaces are not allowed, and upper and lower case is
not significant.
11 defining_operator_symbol ::= operator_symbol
12 parameter_profile ::= [formal_part]
13/2 {AI95-00231-01} {AI95-00318-02} parameter_and_result_profile ::=
[formal_part] return [null_exclusion] subtype_mark
| [formal_part] return access_definition
14 formal_part ::=
(parameter_specification {; parameter_specification})
15/3 {AI95-00231-01} {AI05-0142-4} parameter_specification ::=
defining_identifier_list : [aliased] mode [null_exclusion
] subtype_mark [:= default_expression]
| defining_identifier_list : access_definition
[:= default_expression]
16 mode ::= [in] | in out | out
Name Resolution Rules
17 A formal parameter is an object [directly visible within a
subprogram_body] that represents the actual parameter passed to the subprogram
in a call; it is declared by a parameter_specification. For a formal
parameter, the expected type for its default_expression, if any, is that of
the formal parameter.
Legality Rules
18/3 {AI05-0143-1} The parameter mode of a formal parameter conveys the
direction of information transfer with the actual parameter: in, in out, or
out. Mode in is the default, and is the mode of a parameter defined by an
access_definition.
18.a/3 This paragraph was deleted.{AI05-0143-1}
19 A default_expression is only allowed in a parameter_specification for a
formal parameter of mode in.
20/3 {AI95-00348-01} {AI05-0177-1} {AI05-0229-1} A subprogram_declaration or a
generic_subprogram_declaration requires a completion [unless the Import aspect
(see B.1) is True for the declaration; the completion shall be a body or a
renaming_declaration (see 8.5)]. [A completion is not allowed for an
abstract_subprogram_declaration (see 3.9.3), a null_procedure_declaration (see
6.7), or an expression_function_declaration (see 6.8).]
20.a/3 Ramification: {AI95-00348-01} {AI05-0177-1} Abstract subprograms ,
null procedures, and expression functions are not declared by
subprogram_declarations, and so do not require completion
(although the latter two can be completions). Protected
subprograms are declared by subprogram_declarations, and so
require completion. Note that an abstract subprogram is a
subprogram, a null procedure is a subprogram, an expression
function is a subprogram, and a protected subprogram is a
subprogram, but a generic subprogram is not a subprogram.
20.b/3 Proof: {AI05-0229-1} When the Import aspect is True for any
entity, no completion is allowed (see B.1).
21 A name that denotes a formal parameter is not allowed within the
formal_part in which it is declared, nor within the formal_part of a
corresponding body or accept_statement.
21.a Ramification: By contrast, generic_formal_parameter_declarations
are visible to subsequent declarations in the same
generic_formal_part.
Static Semantics
22 The profile of (a view of) a callable entity is either a
parameter_profile or parameter_and_result_profile[; it embodies information
about the interface to that entity - for example, the profile includes
information about parameters passed to the callable entity. All callable
entities have a profile - enumeration literals, other subprograms, and
entries. An access-to-subprogram type has a designated profile.] Associated
with a profile is a calling convention. A subprogram_declaration declares a
procedure or a function, as indicated by the initial reserved word, with name
and profile as given by its specification.
23/2 {AI95-00231-01} {AI95-00318-02} The nominal subtype of a formal parameter
is the subtype determined by the optional null_exclusion and the
subtype_mark, or defined by the access_definition, in the
parameter_specification. The nominal subtype of a function result is the
subtype determined by the optional null_exclusion and the subtype_mark, or
defined by the access_definition, in the parameter_and_result_profile.
23.1/3 {AI05-0142-4} An explicitly aliased parameter is a formal parameter
whose parameter_specification includes the reserved word aliased.
24/2 {AI95-00231-01} {AI95-00254-01} {AI95-00318-02} An access parameter is a
formal in parameter specified by an access_definition. An access result type
is a function result type specified by an access_definition. An access
parameter or result type is of an anonymous access type (see 3.10). [Access
parameters of an access-to-object type allow dispatching calls to be
controlled by access values. Access parameters of an access-to-subprogram type
permit calls to subprograms passed as parameters irrespective of their
accessibility level.]
24.a/2 Discussion: {AI95-00318-02} Access result types have normal
accessibility and thus don't have any special properties worth
noting here.
25 The subtypes of a profile are:
26 * For any non-access parameters, the nominal subtype of the parameter.
27/2 * {AI95-00254-01} For any access parameters of an access-to-object
type, the designated subtype of the parameter type.
27.1/3 * {AI95-00254-01} {AI05-0164-1} For any access parameters of an
access-to-subprogram type, the subtypes of the designated profile of
the parameter type.
28/2 * {AI95-00231-01} {AI95-00318-02} For any non-access result, the
nominal subtype of the function result.
28.1/2 * {AI95-00318-02} For any access result type of an access-to-object
type, the designated subtype of the result type.
28.2/3 * {AI95-00318-02} {AI05-0164-1} For any access result type of an
access-to-subprogram type, the subtypes of the designated profile of
the result type.
29 [ The types of a profile are the types of those subtypes.]
30/3 {AI95-00348-01} {AI05-0177-1} [A subprogram declared by an
abstract_subprogram_declaration is abstract; a subprogram declared by a
subprogram_declaration is not. See 3.9.3, "Abstract Types and Subprograms".
Similarly, a procedure declared by a null_procedure_declaration is a null
procedure; a procedure declared by a subprogram_declaration is not. See 6.7
, "Null Procedures". Finally, a function declared by an
expression_function_declaration is an expression function; a function declared
by a subprogram_declaration is not. See 6.8, "Expression Functions".]
30.1/2 {AI95-00218-03} [An overriding_indicator is used to indicate whether
overriding is intended. See 8.3.1, "Overriding Indicators".]
Dynamic Semantics
31/2 {AI95-00348-01} The elaboration of a subprogram_declaration has no
effect.
NOTES
32 1 A parameter_specification with several identifiers is equivalent to
a sequence of single parameter_specifications, as explained in 3.3.
33 2 Abstract subprograms do not have bodies, and cannot be used in a
nondispatching call (see 3.9.3, "Abstract Types and Subprograms").
34 3 The evaluation of default_expressions is caused by certain calls,
as described in 6.4.1. They are not evaluated during the elaboration
of the subprogram declaration.
35 4 Subprograms can be called recursively and can be called
concurrently from multiple tasks.
Examples
36 Examples of subprogram declarations:
37 procedure Traverse_Tree;
procedure Increment(X : in out Integer);
procedure Right_Indent(Margin : out Line_Size); -- see 3.5.4
procedure Switch(From, To : in out Link); -- see 3.10.1
38 function Random return Probability; -- see 3.5.7
39/4 {AI12-0056-1}
function Min_Cell(X : Link) return Cell; -- see 3.10.1
function Next_Frame(K : Positive) return Frame; -- see 3.10
function Dot_Product(Left, Right : Vector) return Real; -- see 3.6
function Find(B : aliased in out Barrel; Key : String) return Real;
-- see 4.1.5
40 function "*"(Left, Right : Matrix) return Matrix; -- see 3.6
41 Examples of in parameters with default expressions:
42 procedure Print_Header(Pages : in Natural;
Header : in Line := (1 .. Line'Last => ' '); -- see 3.6
Center : in Boolean := True);
Extensions to Ada 83
42.a The syntax for abstract_subprogram_declaration is added. The
syntax for parameter_specification is revised to allow for access
parameters (see 3.10)
42.b/3 {AI05-0299-1} Program units that are library units may have a
parent_unit_name to indicate the parent of a child (see 10.1.1).
Wording Changes from Ada 83
42.c We have incorporated the rules from RM83-6.5, "Function
Subprograms" here and in 6.3, "Subprogram Bodies"
42.d We have incorporated the definitions of RM83-6.6, "Parameter and
Result Type Profile - Overloading of Subprograms" here.
42.e The syntax rule for defining_operator_symbol is new. It is used
for the defining occurrence of an operator_symbol, analogously to
defining_identifier. Usage occurrences use the direct_name or
selector_name syntactic categories. The syntax rules for
defining_designator and defining_program_unit_name are new.
Extensions to Ada 95
42.f/2 {AI95-00218-03} Subprograms now allow overriding_indicators for
better error checking of overriding.
42.g/2 {AI95-00231-01} An optional null_exclusion can be used in a formal
parameter declaration. Similarly, an optional null_exclusion can
be used in a function result.
42.h/2 {AI95-00318-02} The return type of a function can be an anonymous
access type.
Wording Changes from Ada 95
42.i/2 {AI95-00254-01} A description of the purpose of anonymous
access-to-subprogram parameters and the definition of the profile
of subprograms containing them was added.
42.j/2 {AI95-00348-01} Split the production for
subprogram_specification in order to make the declaration of null
procedures (see 6.7) easier.
42.k/2 {AI95-00348-01} Moved the Syntax and Dynamic Semantics for
abstract_subprogram_declaration to 3.9.3, so that the syntax and
semantics are together. This also keeps abstract and null
subprograms similar.
42.l/2 {AI95-00395-01} Revised to allow other_format characters in
operator_symbols in the same way as the underlying constructs.
Extensions to Ada 2005
42.m/3 {AI05-0142-4} Parameters can now be explicitly aliased, allowing
parts of function results to designate parameters and forcing
by-reference parameter passing.
42.n/3 {AI05-0143-1} The parameters of a function can now have any mode.
42.o/3 {AI05-0183-1} An optional aspect_specification can be used in a
subprogram_declaration. This is described in 13.1.1.
Wording Changes from Ada 2005
42.p/3 {AI05-0177-1} Added expression functions (see 6.8) to the wording.
6.1.1 Preconditions and Postconditions
1/4 {AI05-0145-2} {AI05-0247-1} {AI12-0045-1} For a noninstance subprogram, a
generic subprogram, or an entry, the following language-defined aspects may be
specified with an aspect_specification (see 13.1.1):
1.a/4 Ramification: {AI12-0045-1} "Noninstance subprogram" excludes a
subprogram that is an instance of a generic subprogram. In that
case, the aspects should be specified on the generic subprogram.
If preconditions or postconditions need to be added to an instance
of a generic subprogram, it can be accomplished by creating a
separate subprogram specification and then completing that
specification with a renames-as-body of the instance.
2/3 Pre This aspect specifies a specific precondition for a callable
entity; it shall be specified by an expression, called a
specific precondition expression. If not specified for an
entity, the specific precondition expression for the entity is
the enumeration literal True.
2.a/3 To be honest: In this and the following rules, we are talking
about the enumeration literal True declared in package Standard
(see A.1), and not some other value or identifier True. That
matters as some rules depend on full conformance of these
expressions, which depends on the specific declarations involved.
2.b/3 Aspect Description for Pre: Precondition; a condition that must
hold true before a call.
3/3 {AI05-0254-1} {AI05-0262-1} Pre'Class
This aspect specifies a class-wide precondition for an
operation of a tagged type and its descendants; it shall be
specified by an expression, called a class-wide precondition
expression. If not specified for an entity, then if no other
class-wide precondition applies to the entity, the class-wide
precondition expression for the entity is the enumeration
literal True.
3.a/3 Ramification: {AI05-0254-1} If other class-wide preconditions
apply to the entity and no class-wide precondition is specified,
no class-wide precondition is defined for the entity; of course,
the class-wide preconditions (of ancestors) that apply are still
going to be checked. We need subprograms that don't have ancestors
and don't specify a class-wide precondition to have a class-wide
precondition of True, so that adding such a precondition to a
descendant has no effect (necessary as a dispatching call through
the root routine would not check any precondition).
3.b/3 Aspect Description for Pre'Class: Precondition inherited on type
derivation.
4/3 Post This aspect specifies a specific postcondition for a callable
entity; it shall be specified by an expression, called a
specific postcondition expression. If not specified for an
entity, the specific postcondition expression for the entity
is the enumeration literal True.
4.a/3 Aspect Description for Post: Postcondition; a condition that must
hold true after a call.
5/3 {AI05-0262-1} Post'Class
This aspect specifies a class-wide postcondition for an
operation of a tagged type and its descendants; it shall be
specified by an expression, called a class-wide postcondition
expression. If not specified for an entity, the class-wide
postcondition expression for the entity is the enumeration
literal True.
5.a/3 Aspect Description for Post'Class: Postcondition inherited on type
derivation.
Name Resolution Rules
6/3 {AI05-0145-2} The expected type for a precondition or postcondition
expression is any boolean type.
7/4 {AI05-0145-2} {AI05-0262-1} {AI12-0113-1} {AI12-0159-1} Within the
expression for a Pre'Class or Post'Class aspect for a primitive subprogram S
of a tagged type T, a name that denotes a formal parameter (or S'Result) of
type T is interpreted as though it had a (notional) type NT that is a formal
derived type whose ancestor type is T, with directly visible primitive
operations. Similarly, a name that denotes a formal access parameter (or
S'Result) of type access-to-T is interpreted as having type access-to-NT. [The
result of this interpretation is that the only operations that can be applied
to such names are those defined for such a formal derived type.]
7.a/4 Reason: {AI12-0159-1} This ensures that the expression is
well-defined for any primitive subprogram of a type descended from
T.
8/3 {AI05-0145-2} {AI05-0264-1} For an attribute_reference with
attribute_designator Old, if the attribute reference has an expected type or
shall resolve to a given type, the same applies to the prefix; otherwise, the
prefix shall be resolved independently of context.
Legality Rules
9/3 {AI05-0145-2} {AI05-0230-1} The Pre or Post aspect shall not be specified
for an abstract subprogram or a null procedure. [Only the Pre'Class and
Post'Class aspects may be specified for such a subprogram.]
9.a/3 Discussion: {AI05-0183-1} Pre'Class and Post'Class can only be
specified on primitive routines of tagged types, by a blanket rule
found in 13.1.1.
10/3 {AI05-0247-1} {AI05-0254-1} If a type T has an implicitly declared
subprogram P inherited from a parent type T1 and a homograph (see 8.3) of P
from a progenitor type T2, and
11/3 * the corresponding primitive subprogram P1 of type T1 is neither null
nor abstract; and
12/3 * the class-wide precondition expression True does not apply to P1
(implicitly or explicitly); and
13/3 * there is a class-wide precondition expression that applies to the
corresponding primitive subprogram P2 of T2 that does not fully
conform to any class-wide precondition expression that applies to P1,
14/3 {AI05-0247-1} {AI05-0254-1} then:
15/3 * If the type T is abstract, the implicitly declared subprogram P is
abstract.
16/3 * Otherwise, the subprogram P requires overriding and shall be
overridden with a nonabstract subprogram.
16.a/3 Discussion: We use the term "requires overriding" here so that
this rule is taken into account when calculating visibility in
8.3; otherwise we would have a mess when this routine is
overridden.
16.b/3 Reason: Such an inherited subprogram would necessarily violate the
Liskov Substitutability Principle (LSP) if called via a
dispatching call from an ancestor other than the one that provides
the called body. In such a case, the class-wide precondition of
the actual body is stronger than the class-wide precondition of
the ancestor. If we did not enforce that precondition for the
body, the body could be called when the precondition it knows
about is False - such "counterfeiting" of preconditions has to be
avoided. But enforcing the precondition violates LSP. We do not
want the language to be implicitly creating bodies that violate
LSP; the programmer can still write an explicit body that calls
the appropriate parent subprogram. In that case, the violation of
LSP is explicitly in the code and obvious to code reviewers (both
human and automated).
16.c/3 We have to say that the subprogram is abstract for an abstract
type in this case, so that the next concrete type has to override
it for the reasons above. Otherwise, inserting an extra level of
abstract types would eliminate the requirement to override (as
there is only one declared operation for the concrete type), and
that would be bad for the reasons given above.
16.d/3 Ramification: This requires the set of class-wide preconditions
that apply to the interface routine to be strictly stronger than
those that apply to the concrete routine. Since full conformance
requires each name to denote the same declaration, it is unlikely
that independently declared preconditions would conform. This rule
does allow "diamond inheritance" of preconditions, and of course
no preconditions at all match.
16.e/3 We considered adopting a rule that would allow examples where the
expressions would conform after all inheritance has been applied,
but this is complex and is not likely to be common in practice.
Since the penalty here is just that an explicit overriding is
required, the complexity is too much.
17/3 {AI05-0247-1} If a renaming of a subprogram or entry S1 overrides an
inherited subprogram S2, then the overriding is illegal unless each class-wide
precondition expression that applies to S1 fully conforms to some class-wide
precondition expression that applies to S2 and each class-wide precondition
expression that applies to S2 fully conforms to some class-wide precondition
expression that applies to S1.
17.a/3 Reason: Such an overriding subprogram would violate LSP, as the
precondition of S1 would usually be different (and thus stronger)
than the one known to a dispatching call through an ancestor
routine of S2. This is always OK if the preconditions match, so we
always allow that.
17.b/3 Ramification: This only applies to primitives of tagged types;
other routines cannot have class-wide preconditions.
17.1/4 {AI12-0131-1} Pre'Class shall not be specified for an overriding
primitive subprogram of a tagged type T unless the Pre'Class aspect is
specified for the corresponding primitive subprogram of some ancestor of T.
17.c/4 Reason: Any such Pre'Class will have no effect, as it will be ored
with True. As such, it is highly misleading for readers,
especially for those who are determining the assumptions that can
be made in the body of the primitive subprogram. Note that in this
case there is nothing explicit that might indicate that the
class-wide precondition is ineffective. This rule does not prevent
explicitly writing an ineffective class-wide precondition (for
instance, if the parent subprogram has explicitly specified a
precondition of True).
17.2/4 {AI12-0131-1} In addition to the places where Legality Rules normally
apply (see 12.3), these rules also apply in the private part of an instance of
a generic unit.
Static Semantics
18/4 {AI05-0145-2} {AI12-0113-1} {AI12-0131-1} If a Pre'Class or Post'Class
aspect is specified for a primitive subprogram S of a tagged type T, or such
an aspect defaults to True, then a corresponding expression also applies to
the corresponding primitive subprogram S of each descendant of T. The
corresponding expression is constructed from the associated expression as
follows:
18.a/4 Ramification: A Pre'Class defaults to True only if no class-wide
preconditions are inherited for the subprogram. The same is true
for Post'Class.
18.b/4 Reason: We have to inherit precondition expressions that default
to True, so that later overridings don't strengthen the
precondition (a violation of LSP). We do the same for
postconditions for consistency.
18.1/4 * {AI12-0113-1} References to formal parameters of S (or to S itself)
are replaced with references to the corresponding formal parameters of
the corresponding inherited or overriding subprogram S (or to the
corresponding subprogram S itself).
18.c/4 Reason: We have to define the corresponding expression this way as
overriding routines are only required to be subtype conformant; in
particular, the parameter names can be different. So we have to
talk about corresponding parameters without mentioning any names.
18.2/4 {AI12-0113-1} The primitive subprogram S is illegal if it is not
abstract and the corresponding expression for a Pre'Class or Post'Class aspect
would be illegal.
18.d/4 Ramification: This can happen, for instance, if one of the
subprograms called in the corresponding expression is abstract. We
made the rule general so that we don't have to worry about exactly
which cases can cause this to happen, both now and in the future.
18.e/4 Reason: We allow illegal corresponding expressions on abstract
subprograms as they could never be evaluated, and we need to allow
such expressions to contain calls to abstract subprograms.
19/3 {AI05-0145-2} {AI05-0262-1} {AI05-0290-1} If performing checks is
required by the Pre, Pre'Class, Post, or Post'Class assertion policies (see
11.4.2) in effect at the point of a corresponding aspect specification
applicable to a given subprogram or entry, then the respective precondition or
postcondition expressions are considered enabled.
19.a/3 Ramification: {AI05-0290-1} If a class-wide precondition or
postcondition expression is enabled, it remains enabled when
inherited by an overriding subprogram, even if the policy in
effect is Ignore for the inheriting subprogram.
20/3 {AI05-0273-1} An expression is potentially unevaluated if it occurs
within:
21/3 * any part of an if_expression other than the first condition;
22/3 * a dependent_expression of a case_expression;
22.1/4 * {AI12-0032-1} a predicate of a quantified_expression;
23/3 * the right operand of a short-circuit control form; or
24/3 * a membership_choice other than the first of a membership operation.
25/3 {AI05-0145-2} For a prefix X that denotes an object of a nonlimited type,
the following attribute is defined:
26/4 X'Old {AI05-0145-2} {AI05-0262-1} {AI05-0273-1} {AI12-0032-1} Each
X'Old in a postcondition expression that is enabled denotes a
constant that is implicitly declared at the beginning of the
subprogram body, entry body, or accept statement.
26.1/4 {AI12-0032-1} {AI12-0159-1} The implicitly declared entity
denoted by each occurrence of X'Old is declared as follows:
26.2/4 * If X is of an anonymous access type defined by an
access_definition A then
26.3/4 X'Old : constant A := X;
26.4/4 * If X is of a specific tagged type T then
26.5/4 anonymous : constant T'Class := T'Class(X);
X'Old : T renames T(anonymous);
26.6/4 where the name X'Old denotes the object renaming.
26.a/4 Ramification: This means that the underlying tag associated with
X'Old is that of X and not that of the nominal type of X.
26.7/4 * Otherwise
26.8/4 X'Old : constant S := X;
26.9/4 where S is the nominal subtype of X. This includes the
case where the type of S is an anonymous array type or a
universal type.
26.10/4 {AI12-0032-1} The nominal subtype of X'Old is as implied by
the above definitions. The expected type of the prefix of an
Old attribute is that of the attribute. Similarly, if an Old
attribute shall resolve to be of some type, then the prefix of
the attribute shall resolve to be of that type.
27/3 {AI05-0145-2} {AI05-0262-1} {AI05-0273-1} Reference to this
attribute is only allowed within a postcondition expression.
The prefix of an Old attribute_reference shall not contain a
Result attribute_reference, nor an Old attribute_reference,
nor a use of an entity declared within the postcondition
expression but not within prefix itself (for example, the loop
parameter of an enclosing quantified_expression). The prefix
of an Old attribute_reference that is potentially unevaluated
shall statically denote an entity.
27.a/3 Discussion: The prefix X can be any nonlimited object that obeys
the syntax for prefix other than the few exceptions given above
(discussed below). Useful cases are: the name of a formal
parameter of mode [in] out, the name of a global variable updated
by the subprogram, a function call passing those as parameters, a
subcomponent of those things, etc.
27.b/3 A qualified expression can be used to make an arbitrary expression
into a valid prefix, so T'(X + Y)'Old is legal, even though (X +
Y)'Old is not. The value being saved here is the sum of X and Y (a
function result is an object). Of course, in this case "+"(X,
Y)'Old is also legal, but the qualified expression is arguably
more readable.
27.c/3 Note that F(X)'Old and F(X'Old) are not necessarily equal. The
former calls F(X) and saves that value for later use during the
postcondition. The latter saves the value of X, and during the
postcondition, passes that saved value to F. In most cases, the
former is what one wants (but it is not always legal, see below).
27.d/4 {AI12-0032-1} If X has controlled parts, adjustment and
finalization are implied by the implicit constant declaration.
Similarly, the implicit constant declaration defines the
accessibility level of X'Old.
27.e/3 If postconditions are disabled, we want the compiler to avoid any
overhead associated with saving 'Old values.
27.f/3 'Old makes no sense for limited types, because its implementation
involves copying. It might make semantic sense to allow
build-in-place, but it's not worth the trouble.
27.g/3 Reason: {AI05-0273-1} Since the prefix is evaluated
unconditionally when the subprogram is called, we cannot allow it
to include values that do not exist at that time (like 'Result and
loop parameters of quantified_expressions). We also do not allow
it to include 'Old references, as those would be redundant (the
entire prefix is evaluated when the subprogram is called), and
allowing them would require some sort of order to the implicit
constant declarations (because in A(I'Old)'Old, we surely would
want the value of I'Old evaluated before the A(I'Old) is
evaluated).
27.h/3 {AI05-0273-1} In addition, we only allow simple names as the
prefix of the Old attribute if the attribute_reference might not
be evaluated when the postcondition expression is evaluated. This
is necessary because the Old prefixes have to be unconditionally
evaluated when the subprogram is called; the compiler cannot in
general know whether they will be needed in the postcondition
expression. To see the problem, consider:
27.i/3 Table : array (1..10) of Integer := ...
procedure Bar (I : in out Natural)
with Post => I > 0 and then Table(I)'Old = 1; -- Illegal
27.j/3 In this example, the compiler cannot know the value of I when the
subprogram returns (since the subprogram execution can change it),
and thus it does not know whether Table(I)'Old will be needed
then. Thus it has to always create an implicit constant and
evaluate Table(I) when Bar is called (because not having the value
when it is needed is not acceptable). But if I = 0 when the
subprogram is called, that evaluation will raise Constraint_Error,
and that will happen even if I is unchanged by the subprogram and
the value of Table(I)'Old is not ultimately needed. It's easy to
see how a similar problem could occur for a dereference of an
access type. This would be mystifying (since the point of the
short circuit is to eliminate this possibility, but it cannot do
so). Therefore, we require the prefix of any Old attribute in such
a context to statically denote an object, which eliminates
anything that could change at during execution.
27.k/3 It is easy to work around most errors that occur because of this
rule. Just move the 'Old to the outer object, before any indexing,
dereferences, or components. (That does not work for function
calls, however, nor does it work for array indexing if the index
can change during the execution of the subprogram.)
27.l/4 Ramification: {AI12-0032-1} An accept statement for a task entry
with enabled postconditions such as
27.m/4 accept E do
statements
exception
handlers
end;
27.n/4 behaves (at runtime) as follows:
27.o/4 accept E do
declare
declarations, if any, of 'Old constants
begin
begin
statements
exception
handlers
end;
postcondition checks
end;
end;
27.p/4 {AI12-0032-1} Preconditions are checked by the caller before the
rendezvous begins. Postcondition expressions might, of course,
reference 'Old constants.
27.q/4 {AI12-0032-1} In the case of a protected operation with enabled
postconditions, 'Old constant declarations (if any) are elaborated
after the start of the protected action. Postcondition checks
(which might reference these constants) are performed before the
end of the protected action as described below.
28/3 {AI05-0145-2} For a prefix F that denotes a function declaration, the
following attribute is defined:
29/3 F'Result {AI05-0145-2} {AI05-0262-1} Within a postcondition expression
for function F, denotes the result object of the function. The
type of this attribute is that of the function result except
within a Post'Class postcondition expression for a function
with a controlling result or with a controlling access result.
For a controlling result, the type of the attribute is
T'Class, where T is the function result type. For a
controlling access result, the type of the attribute is an
anonymous access type whose designated type is T'Class, where
T is the designated type of the function result type.
30/3 {AI05-0262-1} Use of this attribute is allowed only within a
postcondition expression for F.
Dynamic Semantics
31/3 {AI05-0145-2} {AI05-0247-1} {AI05-0290-1} Upon a call of the subprogram
or entry, after evaluating any actual parameters, precondition checks are
performed as follows:
32/3 * The specific precondition check begins with the evaluation of the
specific precondition expression that applies to the subprogram or
entry, if it is enabled; if the expression evaluates to False,
Assertions.Assertion_Error is raised; if the expression is not
enabled, the check succeeds.
33/3 * The class-wide precondition check begins with the evaluation of any
enabled class-wide precondition expressions that apply to the
subprogram or entry. If and only if all the class-wide precondition
expressions evaluate to False, Assertions.Assertion_Error is raised.
33.a/3 Ramification: The class-wide precondition expressions of the
entity itself as well as those of any parent or progenitor
operations are evaluated, as these expressions apply to the
corresponding operations of all descendants.
33.b/3 Class-wide precondition checks are performed for all appropriate
calls, but only enabled precondition expressions are evaluated.
Thus, the check would be trivial if no precondition expressions
are enabled.
34/3 {AI05-0145-2} {AI05-0247-1} {AI05-0254-1} {AI05-0269-1} The precondition
checks are performed in an arbitrary order, and if any of the class-wide
precondition expressions evaluate to True, it is not specified whether the
other class-wide precondition expressions are evaluated. The precondition
checks and any check for elaboration of the subprogram body are performed in
an arbitrary order. It is not specified whether in a call on a protected
operation, the checks are performed before or after starting the protected
action. For an entry call, the checks are performed prior to checking whether
the entry is open.
34.a/3 Reason: We need to explicitly allow short-circuiting of the
evaluation of the class-wide precondition check if any expression
fails, as it consists of multiple expressions; we don't need a
similar permission for the specific precondition check as it
consists only of a single expression. Nothing is evaluated for the
call after a check fails, as the failed check propagates an
exception.
35/3 {AI05-0145-2} {AI05-0247-1} {AI05-0254-1} {AI05-0262-1} {AI05-0290-1}
Upon successful return from a call of the subprogram or entry, prior to
copying back any by-copy in out or out parameters, the postcondition check is
performed. This consists of the evaluation of any enabled specific and
class-wide postcondition expressions that apply to the subprogram or entry. If
any of the postcondition expressions evaluate to False, then
Assertions.Assertion_Error is raised. The postcondition expressions are
evaluated in an arbitrary order, and if any postcondition expression evaluates
to False, it is not specified whether any other postcondition expressions are
evaluated. The postcondition check, and any constraint or predicate checks
associated with in out or out parameters are performed in an arbitrary order.
35.a/3 Ramification: The class-wide postcondition expressions of the
entity itself as well as those of any parent or progenitor
operations are evaluated, as these apply to all descendants; in
contrast, only the specific postcondition of the entity applies.
Postconditions can always be evaluated inside the invoked body.
35.1/4 {AI12-0032-1} For a call to a task entry, the postcondition check is
performed before the end of the rendezvous; for a call to a protected
operation, the postcondition check is performed before the end of the
protected action of the call. The postcondition check for any call is
performed before the finalization of any implicitly-declared constants
associated (as described above) with Old attribute_references but after the
finalization of any other entities whose accessibility level is that of the
execution of the callable construct.
35.a.1/4 Reason: {AI12-0032-1} If a postcondition references the
implicitly-declared constant associated with an Old attribute, the
postcondition must be evaluated before the constant is finalized.
One way to think of this is to imagine declaring a controlled
object between any implicit "'Old" constant declarations and any
explicit declarations, then performing postcondition checks during
the finalization of this object.
36/3 {AI05-0145-2} {AI05-0262-1} If a precondition or postcondition check
fails, the exception is raised at the point of the call[; the exception cannot
be handled inside the called subprogram or entry]. Similarly, any exception
raised by the evaluation of a precondition or postcondition expression is
raised at the point of call.
37/4 {AI05-0145-2} {AI05-0247-1} {AI05-0254-1} {AI05-0262-1} {AI12-0113-1}
{AI12-0159-1} For any call to a subprogram or entry S (including dispatching
calls), the checks that are performed to verify specific precondition
expressions and specific and class-wide postcondition expressions are
determined by those for the subprogram or entry actually invoked. Note that
the class-wide postcondition expressions verified by the postcondition check
that is part of a call on a primitive subprogram of type T includes all
class-wide postcondition expressions originating in any progenitor of T[, even
if the primitive subprogram called is inherited from a type T1 and some of the
postcondition expressions do not apply to the corresponding primitive
subprogram of T1]. Any operations within a class-wide postcondition expression
that were resolved as primitive operations of the (notional) formal derived
type NT, are in the evaluation of the postcondition bound to the corresponding
operations of the type identified by the controlling tag of the call on S.[
This applies to both dispatching and non-dispatching calls on S.]
37.a/3 Ramification: This applies to access-to-subprogram calls,
dispatching calls, and to statically bound calls. We need this
rule to cover statically bound calls as well, as specific pre- and
postconditions are not inherited, but the subprogram might be.
37.b/3 For concrete subprograms, we require the original specific
postcondition to be evaluated as well as the inherited class-wide
postconditions in order that the semantics of an explicitly
defined wrapper that does nothing but call the original subprogram
is the same as that of an inherited subprogram.
37.c/3 Note that this rule does not apply to class-wide preconditions;
they have their own rules mentioned below.
38/4 {AI05-0145-2} {AI05-0247-1} {AI05-0254-1} {AI12-0113-1} {AI12-0159-1} The
class-wide precondition check for a call to a subprogram or entry S consists
solely of checking the class-wide precondition expressions that apply to the
denoted callable entity (not necessarily to the one that is invoked). Any
operations within such an expression that were resolved as primitive
operations of the (notional) formal derived type NT are in the evaluation of
the precondition bound to the corresponding operations of the type identified
by the controlling tag of the call on S.[ This applies to both dispatching and
non-dispatching calls on S.]
38.a/3 Ramification: For a dispatching call, we are talking about the
Pre'Class(es) that apply to the subprogram that the dispatching
call is resolving to, not the Pre'Class(es) for the subprogram
that is ultimately dispatched to. The class-wide precondition of
the resolved call is necessarily the same or stronger than that of
the invoked call. For a statically bound call, these are the same;
for an access-to-subprogram, (which has no class-wide
preconditions of its own), we check the class-wide preconditions
of the invoked routine.
38.b/3 Implementation Note: These rules imply that logically, class-wide
preconditions of routines must be checked at the point of call
(other than for access-to-subprogram calls, which must be checked
in the body, probably using a wrapper). Specific preconditions
that might be called with a dispatching call or via an
access-to-subprogram value must be checked inside of the
subprogram body. In contrast, the postcondition checks always need
to be checked inside the body of the routine. Of course, an
implementation can evaluate all of these at the point of call for
statically bound calls if the implementation uses wrappers for
dispatching bodies and for 'Access values.
38.c/3 There is no requirement for an implementation to generate special
code for routines that are imported from outside of the Ada
program. That's because there is a requirement on the programmer
that the use of interfacing aspects do not violate Ada semantics
(see B.1). That includes making pre- and postcondition checks. For
instance, if the implementation expects routines to make their own
postcondition checks in the body before returning, C code can be
assumed to do this (even though that is highly unlikely). That's
even though the formal definition of those checks is that they are
evaluated at the call site. Note that pre- and postconditions can
be very useful for verification tools (even if they aren't
checked), because they tell the tool about the expectations on the
foreign code that it most likely cannot analyze.
39/3 {AI05-0145-2} {AI05-0247-1} {AI05-0254-1} For a call via an
access-to-subprogram value, all precondition and postcondition checks
performed are determined by the subprogram or entry denoted by the prefix of
the Access attribute reference that produced the value.
NOTES
40/3 5 {AI05-0145-2} {AI05-0262-1} A precondition is checked just before
the call. If another task can change any value that the precondition
expression depends on, the precondition need not hold within the
subprogram or entry body.
Extensions to Ada 2005
40.a/3 {AI05-0145-2} {AI05-0230-1} {AI05-0247-1} {AI05-0254-1}
{AI05-0262-1} {AI05-0273-1} {AI05-0274-1} Pre and Post aspects are
new.
Inconsistencies With Ada 2012
40.b/4 {AI12-0032-1} Corrigendum: The Old attribute is defined more
carefully. This changes the nominal subtype and place of
declaration of the attribute compared to the published Ada 2012
Standard. In extreme cases, this could change the runtime behavior
of the attribute (for instance, the tag might be different). The
changes are most likely going to prevent bugs by being more
intuitive, but it is possible that a program that previously
worked might fail.
40.c/4 {AI12-0113-1} {AI12-0159-1} Corrigendum: Eliminated unintentional
redispatching from class-wide preconditions and postconditions.
This means that a different body might be evaluated for a
statically bound call to a routine that has a class-wide
precondition or postcondition. The change means that the behavior
of Pre and Pre'Class will be the same for a particular subprogram,
and that the known behavior of the operations can be assumed
within the body of that subprogram for Pre'Class. We expect that
this change will primarily fix bugs, as it will make Pre'Class and
Post'Class work more like expected. In the case where
redispatching is desired, an explicit conversion to a class-wide
type can be used.
Incompatibilities With Ada 2012
40.d/4 {AI12-0045-1} Corrigendum: Precondition and postcondition aspects
cannot be specified on instances of generic subprograms (they
should be specified on the generic subprogram instead). This was
(unintentionally) allowed by the Ada 2012 standard. These are not
be allowed on instances as there is no corresponding way to add
preconditions and postconditions to subprograms declared within
the instance of a generic package. Therefore, allowing
specification on a subprogram instance could present a maintenance
problem in the future if the entity needs to be converted to a
generic package (a common conversion).
40.e/4 {AI12-0131-1} Corrigendum: Pre'Class is no longer allowed to be
specified for an overriding primitive subprogram unless there are
also inherited class-wide precondittions. This incompatibility
prevents cases where the explicit Pre'Class is counterfeited by an
implicit class-wide precondition of True. This rule should catch
more bugs than it creates; the programmer should have written Pre
rather than Pre'Class in this case (or written Pre'Class on the
original subprogram, not an overriding). Note that this
incompatibility eliminates what otherwise would be an
inconsistency with original Ada 2012, where precondition checks
that would have previously been made for a statically bound call
would no longer be made. That dynamic change was necessary to
eliminate cases where the evaluated class-wide precondition on a
dispatching call would have been weaker than the class-wide
precondition of a statically bound call. (The original Ada 2012
violated the LSP semantics that class-wide preconditions were
intended to model.
6.2 Formal Parameter Modes
1 [A parameter_specification declares a formal parameter of mode in, in out,
or out.]
Static Semantics
2 A parameter is passed either by copy or by reference. [When a parameter is
passed by copy, the formal parameter denotes a separate object from the actual
parameter, and any information transfer between the two occurs only before and
after executing the subprogram. When a parameter is passed by reference, the
formal parameter denotes (a view of) the object denoted by the actual
parameter; reads and updates of the formal parameter directly reference the
actual parameter object.]
3/3 {AI05-0142-4} {AI05-0262-1} A type is a by-copy type if it is an
elementary type, or if it is a descendant of a private type whose full type is
a by-copy type. A parameter of a by-copy type is passed by copy, unless the
formal parameter is explicitly aliased.
4 A type is a by-reference type if it is a descendant of one of the
following:
5 * a tagged type;
6 * a task or protected type;
7/3 * {AI05-0096-1} an explicitly limited record type;
7.a/3 This paragraph was deleted.{AI05-0096-1}
8 * a composite type with a subcomponent of a by-reference type;
9 * a private type whose full type is a by-reference type.
10/4 {AI05-0142-4} {AI05-0188-1} {AI12-0027-1} A parameter of a by-reference
type is passed by reference, as is an explicitly aliased parameter of any
type. Each value of a by-reference type has an associated object. For a
parenthesized expression, qualified_expression, or view conversion, this
object is the one associated with the operand. For a value conversion, the
associated object is the anonymous result object if such an object is created
(see 4.6); otherwise it is the associated object of the operand. For a
conditional_expression, this object is the one associated with the evaluated
dependent_expression.
10.a Ramification: By-reference parameter passing makes sense only if
there is an object to reference; hence, we define such an object
for each case.
10.b Since tagged types are by-reference types, this implies that every
value of a tagged type has an associated object. This simplifies
things, because we can define the tag to be a property of the
object, and not of the value of the object, which makes it clearer
that object tags never change.
10.c We considered simplifying things even more by making every value
(and therefore every expression) have an associated object. After
all, there is little semantic difference between a constant object
and a value. However, this would cause problems for untagged
types. In particular, we would have to do a constraint check on
every read of a type conversion (or a renaming thereof) in certain
cases.
10.d/2 {AI95-00318-02} We do not want this definition to depend on the
view of the type; privateness is essentially ignored for this
definition. Otherwise, things would be confusing (does the rule
apply at the call site, at the site of the declaration of the
subprogram, at the site of the return statement?), and requiring
different calls to use different mechanisms would be an
implementation burden.
10.e C.6, "Shared Variable Control" says that a composite type with an
atomic or volatile subcomponent is a by-reference type, among
other things.
10.f Every value of a limited by-reference type is the value of one and
only one limited object. The associated object of a value of a
limited by-reference type is the object whose value it represents.
Two values of a limited by-reference type are the same if and only
if they represent the value of the same object.
10.g We say "by-reference" above because these statements are not
always true for limited private types whose underlying type is
nonlimited (unfortunately).
11/3 {AI05-0240-1} For other parameters, it is unspecified whether the
parameter is passed by copy or by reference.
11.a/3 Discussion: {AI05-0005-1} There is no need to incorporate the
discussion of AI83-00178, which requires pass-by-copy for certain
kinds of actual parameters, while allowing pass-by-reference for
others. This is because we explicitly indicate that a function
creates an anonymous constant object for its result (see 6.5). We
also provide a special dispensation for instances of
Unchecked_Conversion to return by reference (see 13.9).
Bounded (Run-Time) Errors
12/3 {AI05-0240-1} If one name denotes a part of a formal parameter, and a
second name denotes a part of a distinct formal parameter or an object that is
not part of a formal parameter, then the two names are considered distinct
access paths. If an object is of a type for which the parameter passing
mechanism is not specified and is not an explicitly aliased parameter, then it
is a bounded error to assign to the object via one access path, and then read
the value of the object via a distinct access path, unless the first access
path denotes a part of a formal parameter that no longer exists at the point
of the second access [(due to leaving the corresponding callable construct).]
The possible consequences are that Program_Error is raised, or the newly
assigned value is read, or some old value of the object is read.
12.a Discussion: For example, if we call "P(X => Global_Variable, Y =>
Global_Variable)", then within P, the names "X", "Y", and "
Global_Variable" are all distinct access paths. If
Global_Variable's type is neither pass-by-copy nor
pass-by-reference, then it is a bounded error to assign to
Global_Variable and then read X or Y, since the language does not
specify whether the old or the new value would be read. On the
other hand, if Global_Variable's type is pass-by-copy, then the
old value would always be read, and there is no error. Similarly,
if Global_Variable's type is defined by the language to be
pass-by-reference, then the new value would always be read, and
again there is no error.
12.b Reason: We are saying assign here, not update, because updating
any subcomponent is considered to update the enclosing object.
12.c The "still exists" part is so that a read after the subprogram
returns is OK.
12.d If the parameter is of a by-copy type, then there is no issue here
- the formal is not a view of the actual. If the parameter is of a
by-reference type, then the programmer may depend on updates
through one access path being visible through some other access
path, just as if the parameter were of an access type.
12.e Implementation Note: The implementation can keep a copy in a
register of a parameter whose parameter-passing mechanism is not
specified. If a different access path is used to update the object
(creating a bounded error situation), then the implementation can
still use the value of the register, even though the in-memory
version of the object has been changed. However, to keep the error
properly bounded, if the implementation chooses to read the
in-memory version, it has to be consistent -- it cannot then
assume that something it has proven about the register is true of
the memory location. For example, suppose the formal parameter is
L, the value of L(6) is now in a register, and L(6) is used in an
indexed_component as in "A(L(6)) := 99;", where A has bounds 1..3.
If the implementation can prove that the value for L(6) in the
register is in the range 1..3, then it need not perform the
constraint check if it uses the register value. However, if the
memory value of L(6) has been changed to 4, and the implementation
uses that memory value, then it had better not alter memory
outside of A.
12.f Note that the rule allows the implementation to pass a parameter
by reference and then keep just part of it in a register, or,
equivalently, to pass part of the parameter by reference and
another part by copy.
12.g Reason: We do not want to go so far as to say that the mere
presence of aliasing is wrong. We wish to be able to write the
following sorts of things in standard Ada:
12.h procedure Move ( Source : in String;
Target : out String;
Drop : in Truncation := Error;
Justify : in Alignment := Left;
Pad : in Character := Space);
-- Copies elements from Source to Target (safely if they overlap)
12.i This is from the standard string handling package. It would be
embarrassing if this couldn't be written in Ada!
12.j The "then" before "read" in the rule implies that the
implementation can move a read to an earlier place in the code,
but not to a later place after a potentially aliased assignment.
Thus, if the subprogram reads one of its parameters into a local
variable, and then updates another potentially aliased one, the
local copy is safe - it is known to have the old value. For
example, the above-mentioned Move subprogram can be implemented by
copying Source into a local variable before assigning into Target.
12.k For an assignment_statement assigning one array parameter to
another, the implementation has to check which direction to copy
at run time, in general, in case the actual parameters are
overlapping slices. For example:
12.l procedure Copy(X : in out String; Y: String) is
begin
X := Y;
end Copy;
12.m It would be wrong for the compiler to assume that X and Y do not
overlap (unless, of course, it can prove otherwise).
NOTES
13/4 6 {AI12-0056-1} The mode of a formal parameter describes the
direction of information transfer to or from the subprogram_body (see
6.1).
14 7 A formal parameter of mode in is a constant view (see 3.3); it
cannot be updated within the subprogram_body.
15/4 8 {AI12-0056-1} A formal parameter of mode out might be uninitialized
at the start of the subprogram_body (see 6.4.1).
Extensions to Ada 83
15.a The value of an out parameter may be read. An out parameter is
treated like a declared variable without an explicit initial
expression.
Wording Changes from Ada 83
15.b Discussion of copy-in for parts of out parameters is now covered
in 6.4.1, "Parameter Associations".
15.c The concept of a by-reference type is new to Ada 95.
15.d We now cover in a general way in 3.7.2 the rule regarding
erroneous execution when a discriminant is changed and one of the
parameters depends on the discriminant.
Wording Changes from Ada 2005
15.e/3 {AI05-0096-1} Correction: Corrected so that limited derived types
are by-reference only if their parent is.
15.f/3 {AI05-0142-4} Defined that explicitly aliased parameters (see
6.1) are always passed by reference.
Wording Changes from Ada 2012
15.g/4 {AI05-0027-1} Corrigendum: Corrected so that value conversions
that are copies are the "associated object" for parameter passing
of by-reference types. This can only happen if the conversion is
between unrelated non-limited types, and it is necessary just so
the correct object is defined.
6.3 Subprogram Bodies
1 [A subprogram_body specifies the execution of a subprogram.]
Syntax
2/3 {AI95-00218-03} {AI05-0183-1} subprogram_body ::=
[overriding_indicator]
subprogram_specification
[aspect_specification] is
declarative_part
begin
handled_sequence_of_statements
end [designator];
3 If a designator appears at the end of a subprogram_body, it shall
repeat the defining_designator of the subprogram_specification.
Legality Rules
4 [In contrast to other bodies,] a subprogram_body need not be the
completion of a previous declaration[, in which case the body declares the
subprogram]. If the body is a completion, it shall be the completion of a
subprogram_declaration or generic_subprogram_declaration. The profile of a
subprogram_body that completes a declaration shall conform fully to that of
the declaration.
Static Semantics
5 A subprogram_body is considered a declaration. It can either complete a
previous declaration, or itself be the initial declaration of the subprogram.
Dynamic Semantics
6 The elaboration of a nongeneric subprogram_body has no other effect than
to establish that the subprogram can from then on be called without failing
the Elaboration_Check.
6.a Ramification: See 12.2 for elaboration of a generic body. Note
that protected subprogram_bodies never get elaborated; the
elaboration of the containing protected_body allows them to be
called without failing the Elaboration_Check.
7 [The execution of a subprogram_body is invoked by a subprogram call.] For
this execution the declarative_part is elaborated, and the
handled_sequence_of_statements is then executed.
Examples
8 Example of procedure body:
9 procedure Push(E : in Element_Type; S : in out Stack) is
begin
if S.Index = S.Size then
raise Stack_Overflow;
else
S.Index := S.Index + 1;
S.Space(S.Index) := E;
end if;
end Push;
10 Example of a function body:
11 function Dot_Product(Left, Right : Vector) return Real is
Sum : Real := 0.0;
begin
Check(Left'First = Right'First and Left'Last = Right'Last);
for J in Left'Range loop
Sum := Sum + Left(J)*Right(J);
end loop;
return Sum;
end Dot_Product;
Extensions to Ada 83
11.a A renaming_declaration may be used instead of a subprogram_body.
Wording Changes from Ada 83
11.b The syntax rule for subprogram_body now uses the syntactic
category handled_sequence_of_statements.
11.c The declarative_part of a subprogram_body is now required; that
doesn't make any real difference, because a declarative_part can
be empty.
11.d We have incorporated some rules from RM83-6.5 here.
11.e RM83 forgot to restrict the definition of elaboration of a
subprogram_body to nongenerics.
Wording Changes from Ada 95
11.f/2 {AI95-00218-03} Overriding_indicator is added to subprogram_body.
Extensions to Ada 2005
11.g/3 {AI05-0183-1} An optional aspect_specification can be used in a
subprogram_body. This is described in 13.1.1.
6.3.1 Conformance Rules
1 [When subprogram profiles are given in more than one place, they are
required to conform in one of four ways: type conformance, mode conformance,
subtype conformance, or full conformance.]
Static Semantics
2/1 {8652/0011} {AI95-00117-01} [As explained in B.1, "Interfacing Aspects", a
convention can be specified for an entity.] Unless this International Standard
states otherwise, the default convention of an entity is Ada. [For a callable
entity or access-to-subprogram type, the convention is called the calling
convention.] The following conventions are defined by the language:
3/3 * {AI05-0229-1} The default calling convention for any subprogram not
listed below is Ada. [The Convention aspect may be specified to
override the default calling convention (see B.1)].
3.a Ramification: See also the rule about renamings-as-body in 8.5.4.
4 * The Intrinsic calling convention represents subprograms that are "
built in" to the compiler. The default calling convention is Intrinsic
for the following:
5 * an enumeration literal;
6 * a "/=" operator declared implicitly due to the declaration of "="
(see 6.6);
7 * any other implicitly declared subprogram unless it is a
dispatching operation of a tagged type;
8 * an inherited subprogram of a generic formal tagged type with
unknown discriminants;
8.a.1/1 Reason: Consider:
8.a.2/1 package P is
type Root is tagged null record;
procedure Proc(X: Root);
end P;
8.a.3/1 generic
type Formal(<>) is new Root with private;
package G is
...
end G;
8.a.4/1 package body G is
...
X: Formal := ...;
...
Proc(X); -- This is a dispatching call in Instance, because
-- the actual type for Formal is class-wide.
...
-- Proc'Access would be illegal here, because it is of
-- convention Intrinsic, by the above rule.
end G;
8.a.5/1 type Actual is new Root with ...;
procedure Proc(X: Actual);
package Instance is new G(Formal => Actual'Class);
-- It is legal to pass in a class-wide actual, because Formal
-- has unknown discriminants.
8.a.6/1 Within Instance, all calls to Proc will be dispatching calls, so
Proc doesn't really exist in machine code, so we wish to avoid
taking 'Access of it. This rule applies to those cases where the
actual type might be class-wide, and makes these Intrinsic, thus
forbidding 'Access.
9 * an attribute that is a subprogram;
10/2 * {AI95-00252-01} a subprogram declared immediately within a
protected_body;
10.1/4 * {AI95-00252-01} {AI95-00407-01} {AI12-0107-1} any prefixed view of
a subprogram (see 4.1.3) without synchronization kind (see 9.5)
By_Entry or By_Protected_Procedure.
10.a/2 Reason: The profile of a prefixed view is different than the "
real" profile of the subprogram (it doesn't have the first parameter),
so we don't want to be able to take 'Access of it, as that would
require generating a wrapper of some sort.
10.b/4 {AI12-0107-1} We except prefixed views that have synchronization
kind By_Protected_Procedure so that they can be used with an
access-to-protected-procedure type. These don't require special
wrappers (this is the normal form for a protected subprogram
call). The By_Entry part is just for consistency (there is no
access-to-entry type in Ada).
11 [The Access attribute is not allowed for Intrinsic subprograms.]
11.a Ramification: The Intrinsic calling convention really represents
any number of calling conventions at the machine code level; the
compiler might have a different instruction sequence for each
intrinsic. That's why the Access attribute is disallowed. We do
not wish to require the implementation to generate an out of line
body for an intrinsic.
11.b/3 {AI05-0229-1} Whenever we wish to disallow the Access attribute in
order to ease implementation, we make the subprogram Intrinsic.
Several language-defined subprograms have "with Convention =>
Intrinsic;". An implementation might actually implement this as
"with Import => True, Convention => Intrinsic;", if there is
really no body, and the implementation of the subprogram is built
into the code generator.
11.c Subprograms declared in protected_bodies will generally have a
special calling convention so as to pass along the identification
of the current instance of the protected type. The convention is
not protected since such local subprograms need not contain any
"locking" logic since they are not callable via "external" calls;
this rule prevents an access value designating such a subprogram
from being passed outside the protected unit.
11.d The "implicitly declared subprogram" above refers to predefined
operators (other than the "=" of a tagged type) and the inherited
subprograms of untagged types.
12/4 * {AI12-0107-1} {AI12-0159-1} The default calling convention is
protected for a protected subprogram, for a prefixed view of a
subprogram with a synchronization kind of By_Protected_Procedure, and
for an access-to-subprogram type with the reserved word protected in
its definition.
13/4 * {AI12-0107-1} {AI12-0159-1} The default calling convention is entry
for an entry and for a prefixed view of a subprogram with a
synchronization kind of By_Entry.
13.1/3 * {AI95-00254-01} {AI95-00409-01} {AI05-0264-1} The calling
convention for an anonymous access-to-subprogram parameter or
anonymous access-to-subprogram result is protected if the reserved
word protected appears in its definition; otherwise, it is the
convention of the subprogram that contains the parameter.
13.a/2 Ramification: The calling convention for other anonymous
access-to-subprogram types is Ada.
13.2/1 * {8652/0011} {AI95-00117-01} [If not specified above as Intrinsic,
the calling convention for any inherited or overriding dispatching
operation of a tagged type is that of the corresponding subprogram of
the parent type.] The default calling convention for a new dispatching
operation of a tagged type is the convention of the type.
13.a.1/1 Reason: The first rule is officially stated in 3.9.2. The second
is intended to make interfacing to foreign OOP languages easier,
by making the default be that the type and operations all have the
same convention.
14/3 {AI05-0229-1} Of these four conventions, only Ada and Intrinsic are
allowed as a convention_identifier in the specification of a Convention
aspect.
14.a/3 Discussion: {AI05-0229-1} The names of the protected and entry
calling conventions cannot be used in the specification of
Convention. Note that protected and entry are reserved words.
15/2 {AI95-00409-01} Two profiles are type conformant if they have the same
number of parameters, and both have a result if either does, and corresponding
parameter and result types are the same, or, for access parameters or access
results, corresponding designated types are the same, or corresponding
designated profiles are type conformant.
15.a/2 Discussion: {AI95-00409-01} For anonymous access-to-object
parameters, the designated types have to be the same for type
conformance, not the access types, since in general each access
parameter has its own anonymous access type, created when the
subprogram is called. Of course, corresponding parameters have to
be either both access parameters or both not access parameters.
15.b/2 {AI95-00409-01} Similarly, for anonymous access-to-subprogram
parameters, the designated profiles of the types, not the types
themselves, have to be conformant.
16/3 {AI95-00318-02} {AI95-00409-01} {AI05-0142-4} Two profiles are mode
conformant if:
16.1/3 * {AI05-0142-4} {AI05-0262-1} they are type conformant; and
16.2/3 * {AI05-0142-4} corresponding parameters have identical modes and
both or neither are explicitly aliased parameters; and
16.3/3 * {AI05-0207-1} for corresponding access parameters and any access
result type, the designated subtypes statically match and either both
or neither are access-to-constant, or the designated profiles are
subtype conformant.
17/3 {AI05-0239-1} Two profiles are subtype conformant if they are mode
conformant, corresponding subtypes of the profile statically match, and the
associated calling conventions are the same. The profile of a generic formal
subprogram is not subtype conformant with any other profile.
17.a Ramification:
18/3 {AI05-0134-1} {AI05-0262-1} Two profiles are fully conformant if they are
subtype conformant, if they have access-to-subprogram results whose designated
profiles are fully conformant, and for corresponding parameters:
18.1/3 * {AI05-0262-1} they have the same names; and
18.2/3 * {AI05-0046-1} both or neither have null_exclusions; and
18.3/3 * neither have default_expressions, or they both have
default_expressions that are fully conformant with one another; and
18.4/3 * {AI05-0134-1} for access-to-subprogram parameters, the designated
profiles are fully conformant.
18.a Ramification: Full conformance requires subtype conformance, which
requires the same calling conventions. However, the calling
convention of the declaration and body of a subprogram or entry
are always the same by definition.
18.b/3 Reason: {AI05-0046-1} The part about null_exclusions is necessary
to prevent controlling parameters from having different
exclusions, as such a parameter is defined to exclude null whether
or not an exclusion is given.
18.c/3 {AI05-0134-1} The parts about access-to-subprogram parameters and
results is necessary to prevent such types from having different
default_expressions in the specification and body of a subprogram.
If that was allowed, it would be undefined which
default_expression was used in a call of an access-to-subprogram
parameter.
19 Two expressions are fully conformant if, [after replacing each use of an
operator with the equivalent function_call:]
20 * each constituent construct of one corresponds to an instance of the
same syntactic category in the other, except that an expanded name may
correspond to a direct_name (or character_literal) or to a different
expanded name in the other; and
20.1/4 * {AI12-0050-1} corresponding defining_identifiers occurring within
the two expressions are the same; and
21/4 * {AI12-0050-1} each direct_name, character_literal, and
selector_name that is not part of the prefix of an expanded name in
one denotes the same declaration as the corresponding direct_name,
character_literal, or selector_name in the other, or they denote
corresponding declarations occurring within the two expressions; and
21.a Ramification: Note that it doesn't say "respectively" because a
direct_name can correspond to a selector_name, and vice-versa, by
the previous bullet. This rule allows the prefix of an expanded
name to be removed, or replaced with a different prefix that
denotes a renaming of the same entity. However, it does not allow
a direct_name or selector_name to be replaced with one denoting a
distinct renaming (except for direct_names and selector_names in
prefixes of expanded names). Note that calls using operator
notation are equivalent to calls using prefix notation.
21.b Given the following declarations:
21.c package A is
function F(X : Integer := 1) return Boolean;
end A;
21.c.1/3 {AI05-0005-1} with A;
package B is
package A_View renames A;
function F_View(X : Integer := 9999) return Boolean renames A.F;
end B;
21.d with A, B; use A, B;
procedure Main is ...
21.e Within Main, the expressions "F", "A.F", "B.A_View.F", and "
A_View.F" are all fully conformant with one another. However, "
F" and "F_View" are not fully conformant. If they were, it would be
bad news, since the two denoted views have different
default_expressions.
21.f/4 Discussion: {AI12-0050-1} We talk about defining_identifiers and
"corresponding declarations" because of the possibility of
iterator_specifications occurring within the expressions; each
iterator_specification is a separate declaration, which we need to
allow, but we do want to require that the defining_identifiers are
the same.
21.1/3 * {8652/0018} {AI95-00175-01} {AI05-0092-1} each
attribute_designator in one is the same as the corresponding
attribute_designator in the other; and
22 * each primary that is a literal in one has the same value as the
corresponding literal in the other.
22.a Ramification: The literals may be written differently.
22.b Ramification: Note that the above definition makes full
conformance a transitive relation.
23 Two known_discriminant_parts are fully conformant if they have the same
number of discriminants, and discriminants in the same positions have the same
names, statically matching subtypes, and default_expressions that are fully
conformant with one another.
24 Two discrete_subtype_definitions are fully conformant if they are both
subtype_indications or are both ranges, the subtype_marks (if any) denote the
same subtype, and the corresponding simple_expressions of the ranges (if any)
fully conform.
24.a Ramification: In the subtype_indication case, any ranges have to
be corresponding; that is, two subtype_indications cannot conform
unless both or neither has a range.
24.b Discussion: This definition is used in 9.5.2, "
Entries and Accept Statements" for the conformance required
between the discrete_subtype_definitions of an entry_declaration
for a family of entries and the corresponding
entry_index_specification of the entry_body.
24.1/2 {AI95-00345-01} {AI95-00397-01} The prefixed view profile of a
subprogram is the profile obtained by omitting the first parameter of that
subprogram. There is no prefixed view profile for a parameterless subprogram.
For the purposes of defining subtype and mode conformance, the convention of a
prefixed view profile is considered to match that of either an entry or a
protected operation.
24.c/2 Discussion: This definition is used to define how primitive
subprograms of interfaces match operations in task and protected
type definitions (see 9.1 and 9.4).
24.d/2 Reason: The weird rule about conventions is pretty much required
for synchronized interfaces to make any sense. There will be
wrappers all over the place for interfaces anyway. Of course, this
doesn't imply that entries have the same convention as protected
operations.
Implementation Permissions
25 An implementation may declare an operator declared in a language-defined
library unit to be intrinsic.
Extensions to Ada 83
25.a The rules for full conformance are relaxed - they are now based on
the structure of constructs, rather than the sequence of lexical
elements. This implies, for example, that "(X, Y: T)" conforms
fully with "(X: T; Y: T)", and "(X: T)" conforms fully with "(X:
in T)".
Wording Changes from Ada 95
25.b/2 {8652/0011} {AI95-00117-01} Corrigendum: Clarified that the
default convention is Ada. Also clarified that the convention of a
primitive operation of a tagged type is the same as that of the
type.
25.c/2 {8652/0018} {AI95-00175-01} Corrigendum: Added wording to ensure
that two attributes conform only if they have the same
attribute_designator.
25.d/2 {AI95-00252-01} {AI95-00254-01} {AI95-00407-01} Defined the
calling convention for anonymous access-to-subprogram types and
for prefixed views of subprograms (see 4.1.3).
25.e/2 {AI95-00318-02} Defined the conformance of access result types
(see 6.1).
25.f/2 {AI95-00345-01} {AI95-00397-01} Defined the prefixed view profile
of subprograms for later use.
25.g/2 {AI95-00409-01} Defined the conformance of anonymous
access-to-subprogram parameters.
Incompatibilities With Ada 2005
25.h/3 {AI05-0046-1} Correction: Now require null_exclusions to match for
full conformance. While this is technically incompatible with Ada
2005 as defined by Amendment 1, it is a new Ada 2005 feature and
it is unlikely that users have been intentionally taking advantage
of the ability to write mismatching exclusions. In any case, it is
easy to fix: add a null_exclusion where needed for conformance.
25.i/3 {AI05-0134-1} Correction: Now require full conformance of
anonymous access-to-subprogram parameters and results for full
conformance. This is necessary so that there is no confusion about
the default expression that is used for a call. While this is
technically incompatible with Ada 2005 as defined by Amendment 1,
it is a new Ada 2005 feature and it is unlikely that users have
been intentionally taking advantage and writing different default
expressions. In any case, it is easy to fix: change any default
expressions that don't conform so that they do conform.
25.j/3 {AI05-0207-1} Correction: Now include the presence or absence of
constant in access parameters to be considered when checking mode
conformance. This is necessary to prevent modification of
constants. While this is technically incompatible with Ada 2005 as
defined by Amendment 1, it is a new Ada 2005 feature and it is
unlikely that users have been intentionally taking advantage and
writing mismatching access types.
Wording Changes from Ada 2005
25.k/3 {AI05-0142-4} Explicitly aliased parameters are included as part
of mode conformance (since it affects the parameter passing
mechanism).
Extensions to Ada 2012
25.l/4 {AI05-0107-1} {AI05-0159-1} Corrigendum: We now define that a
prefixed view of a subprogram with synchronization kind
By_Protected_Procedure can be used as the prefix of 'Access for an
access-to-protected type. We consider this a correction as it
certainly appears that it ought to work, but in original Ada 2012
it would have had a convention mismatch.
Wording Changes from Ada 2012
25.m/4 {AI05-0050-1} Corrigendum: We now define how two expressions
containing quantified expressions can fully conform. This isn't
incompatible, as the original Ada 2012 never allowed such
expressions to conform (the declarations in each formally being
different). Neither is it an extension as one would expect these
to conform.
6.3.2 Inline Expansion of Subprograms
1 [Subprograms may be expanded in line at the call site.]
Paragraphs 2 through 4 were moved to Annex J, "Obsolescent Features".
Static Semantics
5/3 {AI05-0229-1} For a callable entity or a generic subprogram, the following
language-defined representation aspect may be specified:
5.1/3 Inline The type of aspect Inline is Boolean. When aspect Inline is
True for a callable entity, inline expansion is desired for
all calls to that entity. When aspect Inline is True for a
generic subprogram, inline expansion is desired for all calls
to all instances of that generic subprogram.
5.2/3 If directly specified, the aspect_definition shall be a static
expression. [This aspect is never inherited;] if not directly
specified, the aspect is False.
5.a/3 Aspect Description for Inline: For efficiency, Inline calls are
requested for a subprogram.
5.b/3 This paragraph was deleted.{AI05-0229-1}
5.c/3 This paragraph was deleted.
5.d/3 This paragraph was deleted.
5.e/3 Ramification: {AI05-0229-1} The meaning of a subprogram can be
changed by inline expansion as requested by aspect Inline only in
the presence of failing checks (see 11.6).
Implementation Permissions
6/3 {AI05-0229-1} For each call, an implementation is free to follow or to
ignore the recommendation determined by the Inline aspect.
6.a Ramification: Note, in particular, that the recommendation cannot
always be followed for a recursive call, and is often infeasible
for entries. Note also that the implementation can inline calls
even when no such desire was expressed via the Inline aspect, so
long as the semantics of the program remains unchanged.
Incompatibilities With Ada 83
7.a/3 This paragraph was deleted.{AI95-00309-01} {AI05-0229-1}
Extensions to Ada 83
7.b/3 This paragraph was deleted.{AI05-0229-1}
Extensions to Ada 95
7.c/3 This paragraph was deleted.{AI95-00309-01} {AI05-0229-1}
Extensions to Ada 2005
7.d/3 {AI05-0229-1} Aspect Inline is new; pragma Inline is now
obsolescent.
6.4 Subprogram Calls
1 A subprogram call is either a procedure_call_statement or a
function_call; [it invokes the execution of the subprogram_body. The call
specifies the association of the actual parameters, if any, with formal
parameters of the subprogram.]
Syntax
2 procedure_call_statement ::=
procedure_name;
| procedure_prefix actual_parameter_part;
3 function_call ::=
function_name
| function_prefix actual_parameter_part
3.a/3 To be honest: {AI05-0005-1} For the purpose of non-syntax rules,
infix operator calls are considered function_calls. See 6.6.
4 actual_parameter_part ::=
(parameter_association {, parameter_association})
5 parameter_association ::=
[formal_parameter_selector_name =>] explicit_actual_parameter
6 explicit_actual_parameter ::= expression | variable_name
7 A parameter_association is named or positional according to whether or
not the formal_parameter_selector_name is specified. Any positional
associations shall precede any named associations. Named associations
are not allowed if the prefix in a subprogram call is an attribute_-
reference.
7.a Ramification: This means that the formal parameter names used in
describing predefined attributes are to aid presentation of their
semantics, but are not intended for use in actual calls.
Name Resolution Rules
8/2 {AI95-00310-01} The name or prefix given in a procedure_call_statement
shall resolve to denote a callable entity that is a procedure, or an entry
renamed as (viewed as) a procedure. The name or prefix given in a
function_call shall resolve to denote a callable entity that is a function.
The name or prefix shall not resolve to denote an abstract subprogram unless
it is also a dispatching subprogram. [When there is an actual_parameter_-
part, the prefix can be an implicit_dereference of an access-to-subprogram
value.]
8.a.1/2 Discussion: {AI95-00310-01} This rule is talking about dispatching
operations (which is a static concept) and not about dispatching
calls (which is a dynamic concept).
8.a Ramification: The function can be an operator, enumeration
literal, attribute that is a function, etc.
9 A subprogram call shall contain at most one association for each formal
parameter. Each formal parameter without an association shall have a
default_expression (in the profile of the view denoted by the name or prefix
). [This rule is an overloading rule (see 8.6).]
9.a/3 Proof: {AI05-0240-1} All Name Resolution Rules are overloading
rules, see 8.6.
Dynamic Semantics
10/2 {AI95-00345-01} For the execution of a subprogram call, the name or
prefix of the call is evaluated, and each parameter_association is evaluated
(see 6.4.1). If a default_expression is used, an implicit
parameter_association is assumed for this rule. These evaluations are done in
an arbitrary order. The subprogram_body is then executed, or a call on an
entry or protected subprogram is performed (see 3.9.2). Finally, if the
subprogram completes normally, then after it is left, any necessary assigning
back of formal to actual parameters occurs (see 6.4.1).
10.a Discussion: The implicit association for a default is only for
this run-time rule. At compile time, the visibility rules are
applied to the default at the place where it occurs, not at the
place of a call.
10.b To be honest: If the subprogram is inherited, see 3.4, "
Derived Types and Classes".
10.c If the subprogram is protected, see 9.5.1, "
Protected Subprograms and Protected Actions".
10.d If the subprogram is really a renaming of an entry, see 9.5.3,
"Entry Calls".
10.d.1/2 {AI95-00345-01} If the subprogram is implemented by an entry or
protected subprogram, it will be treated as a dispatching call to
the corresponding entry (see 9.5.3, "Entry Calls") or protected
subprogram (see 9.5.1, "
Protected Subprograms and Protected Actions").
10.e/2 {AI95-00348-01} Normally, the subprogram_body that is executed by
the above rule is the one for the subprogram being called. For an
enumeration literal, implicitly declared (but noninherited)
subprogram, null procedure, or an attribute that is a subprogram,
an implicit body is assumed. For a dispatching call, 3.9.2, "
Dispatching Operations of Tagged Types" defines which
subprogram_body is executed.
10.1/2 {AI95-00407-01} If the name or prefix of a subprogram call denotes a
prefixed view (see 4.1.3), the subprogram call is equivalent to a call on the
underlying subprogram, with the first actual parameter being provided by the
prefix of the prefixed view (or the Access attribute of this prefix if the
first formal parameter is an access parameter), and the remaining actual
parameters given by the actual_parameter_part, if any.
11/2 {AI95-00318-02} The exception Program_Error is raised at the point of a
function_call if the function completes normally without executing a return
statement.
11.a Discussion: We are committing to raising the exception at the
point of call, for uniformity - see AI83-00152. This happens after
the function is left, of course.
11.b Note that there is no name for suppressing this check, since the
check imposes no time overhead and minimal space overhead (since
it can usually be statically eliminated as dead code).
12/2 {AI95-00231-01} A function_call denotes a constant, as defined in 6.5;
the nominal subtype of the constant is given by the nominal subtype of the
function result.
Examples
13 Examples of procedure calls:
14 Traverse_Tree; -- see 6.1
Print_Header(128, Title, True); -- see 6.1
15 Switch(From => X, To => Next); -- see 6.1
Print_Header(128, Header => Title, Center => True); -- see 6.1
Print_Header(Header => Title, Center => True, Pages => 128); -- see 6.1
16 Examples of function calls:
17 Dot_Product(U, V) -- see 6.1 and 6.3
Clock -- see 9.6
F.all -- presuming F is of an access-to-subprogram type - see 3.10
18 Examples of procedures with default expressions:
19 procedure Activate(Process : in Process_Name;
After : in Process_Name := No_Process;
Wait : in Duration := 0.0;
Prior : in Boolean := False);
20/3 {AI05-0299-1}
procedure Pair(Left, Right : in Person_Name := new Person(M)); -- see 3.10.1
21 Examples of their calls:
22 Activate(X);
Activate(X, After => Y);
Activate(X, Wait => 60.0, Prior => True);
Activate(X, Y, 10.0, False);
23/3 {AI05-0299-1} Pair;
Pair(Left => new Person(F), Right => new Person(M));
NOTES
24 9 If a default_expression is used for two or more parameters in a
multiple parameter_specification, the default_expression is evaluated
once for each omitted parameter. Hence in the above examples, the two
calls of Pair are equivalent.
Examples
25 Examples of overloaded subprograms:
26 procedure Put(X : in Integer);
procedure Put(X : in String);
27 procedure Set(Tint : in Color);
procedure Set(Signal : in Light);
28 Examples of their calls:
29 Put(28);
Put("no possible ambiguity here");
30 Set(Tint => Red);
Set(Signal => Red);
Set(Color'(Red));
31 -- Set(Red) would be ambiguous since Red may
-- denote a value either of type Color or of type Light
Wording Changes from Ada 83
31.a We have gotten rid of parameters "of the form of a type
conversion" (see RM83-6.4.1(3)). The new view semantics of type_conversions
allows us to use normal type_conversions instead.
31.b We have moved wording about run-time semantics of parameter
associations to 6.4.1.
31.c We have moved wording about raising Program_Error for a function
that falls off the end to here from RM83-6.5.
Extensions to Ada 95
31.d/2 {AI95-00310-01} Nondispatching abstract operations are no longer
considered when resolving a subprogram call. That makes it
possible to use abstract to "undefine" a predefined operation for
an untagged type. That's especially helpful when defining custom
arithmetic packages.
Wording Changes from Ada 95
31.e/2 {AI95-00231-01} Changed the definition of the nominal subtype of a
function_call to use the nominal subtype wording of 6.1, to take
into account null_exclusions and access result types.
31.f/2 {AI95-00345-01} Added wording to clarify that the meaning of a
call on a subprogram "implemented by" an entry or protected
operation is defined by 3.9.2.
31.g/2 {AI95-00407-01} Defined the meaning of a call on a prefixed view
of a subprogram (see 4.1.3).
6.4.1 Parameter Associations
1 [ 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.
1.b/3 {AI05-0142-4} For explicitly aliased parameters of functions, we
will ensure at the call site that a part of the parameter can be
returned as part of the function result without creating a
dangling pointer. We do this with accessibility checks at the call
site that all actual objects of explicitly aliased parameters live
at least as long as the function result; then we can allow them to
be returned as access discriminants or anonymous access results,
as those have the master of the function result.
Name Resolution Rules
2/3 {AI05-0118-1} The formal_parameter_selector_name of a named parameter_-
association shall resolve to denote a parameter_specification of the view
being called; this is the formal parameter of the association. The formal
parameter for a positional parameter_association is the parameter with the
corresponding position in the formal part of the view being called.
2.a/3 To be honest: {AI05-0118-1} For positional parameters, the "
corresponding position" is calculated after any transformation of
prefixed views.
3 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. 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/4 Ramification: {AI12-0005-1} This formally resolves the ambiguity
present in the syntax rule for explicit_actual_parameter. This
matters as an expression that is a name is evaluated and
represents a value while a name by itself can be an object; if the
mode is not in, we want the parameter to interpreted as an object.
Note that we don't actually require that the actual be a name if
the mode is not in; we do that below.
4.b/4 {AI12-0005-1} This wording uses "interpreted as" rather than
"shall be" so that this rule is not used to resolve overloading;
it is solely about evaluation as described above. We definitely do
not want to allow oddities like the presence of parentheses
requiring the selection of an in formal parameter as opposed to an
otherwise matching in out parameter.
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.
5.1/4 {AI12-0074-1} {AI12-0159-1} If the mode is out, the actual parameter is
a view conversion, and the type of the formal parameter is an access type or a
scalar type that has the Default_Value aspect specified, then
5.2/4 * there shall exist a type (other than a root numeric type) that is an
ancestor of both the target type and the operand type; and
5.3/4 * in the case of a scalar type, the type of the operand of the
conversion shall have the Default_Value aspect specified.
5.4/4 {AI12-0074-1} {AI12-0159-1} In addition to the places where
Legality Rules normally apply (see 12.3), these rules also apply in the
private part of an instance of a generic unit.
5.e/4 Reason: These rules are needed in order to ensure that a
well-defined parameter value is passed.
6/3 {AI05-0102-1} {AI05-0142-4} If the formal parameter is an explicitly
aliased parameter, the type of the actual parameter shall be tagged or the
actual parameter shall be an aliased view of an object. Further, if the formal
parameter subtype F is untagged:
6.1/3 * the subtype F shall statically match the nominal subtype of the
actual object; or
6.2/3 * the subtype F shall be unconstrained, discriminated in its full
view, and unconstrained in any partial view.
6.a/3 Ramification: Tagged objects (and tagged aggregates for in
parameters) do not need to be aliased. This matches the behavior
of unaliased formal parameters of tagged types, which allow
'Access to be taken of the formal parameter regardless of the form
of the actual parameter.
6.b/3 Reason: We need the subtype check on untagged actual parameters so
that the requirements of 'Access are not lost. 'Access makes its
checks against the nominal subtype of its prefix, and parameter
passing can change that subtype. But we don't want this parameter
passing to change the objects that would be allowed as the prefix
of 'Access. This is particularly important for arrays, where we
don't want to require any additional implementation burden.
6.b.1/4 Discussion: {AI12-0095-1} We assume the worst in a generic body
whether or not a formal subtype has a constrained partial view;
specifically, in a generic body a discriminated subtype is
considered to have a constrained partial view if it is a
descendant of an untagged generic formal private or derived type
(see 12.5.1 for the formal definition of this rule).
6.3/4 {AI12-0095-1} In addition to the places where Legality Rules normally
apply (see 12.3), these rules also apply in the private part of an instance of
a generic unit.
6.4/3 {AI05-0142-4} {AI05-0234-1} In a function call, the accessibility level
of the actual object for each explicitly aliased parameter shall not be
statically deeper than the accessibility level of the master of the call (see
3.10.2).
6.c/3 Discussion: Since explicitly aliased parameters are either tagged
or required to be objects, there is always an object (possibly
anonymous) to talk about. This is discussing the static
accessibility level of the actual object; it does not depend on
any runtime information (for instance when the actual object is a
formal parameter of another subprogram, it does not depend on the
actual parameter of that other subprogram).
6.d/4 Ramification: {AI12-0095-1} This accessibility check (and its
dynamic cousin as well) can only fail if the master of the
function call (which is defined in the Heart of Darkness, or
3.10.2 if you prefer) is different than the master directly
enclosing the call. The most likely place where this will occur is
in the initializer of an allocator; in almost all other cases this
check will always pass.
6.5/3 {AI05-0144-2} Two names are known to denote the same object if:
6.6/3 * both names statically denote the same stand-alone object or
parameter; or
6.7/3 * both names are selected_components, their prefixes are known to
denote the same object, and their selector_names denote the same
component; or
6.8/3 * both names are dereferences (implicit or explicit) and the
dereferenced names are known to denote the same object; or
6.9/3 * both names are indexed_components, their prefixes are known to
denote the same object, and each of the pairs of corresponding index
values are either both static expressions with the same static value
or both names that are known to denote the same object; or
6.10/3 * both names are slices, their prefixes are known to denote the same
object, and the two slices have statically matching index constraints;
or
6.11/3 * one of the two names statically denotes a renaming declaration
whose renamed object_name is known to denote the same object as the
other, the prefix of any dereference within the renamed object_name is
not a variable, and any expression within the renamed object_name
contains no references to variables nor calls on nonstatic functions.
6.e/3 Reason: This exposes known renamings of slices, indexing, and so
on to this definition. In particular, if we have
6.f/3 C : Character renames S(1);
6.g/3 then C and S(1) are known to denote the same object.
6.h/3 We need the requirement that no variables occur in the prefixes of
dereferences and in (index) expressions of the renamed object in
order to avoid problems from later changes to those parts of
renamed names. Consider:
6.i/3 type Ref is access Some_Type;
Ptr : Ref := new Some_Type'(...);
X : Some_Type renames Ptr.all;
begin
Ptr := new Some_Type'(...);
P (Func_With_Out_Params (Ptr.all), X);
6.j/3 X and Ptr.all should not be known to denote the same object, since
they denote different allocated objects (and this is not an
unreasonable thing to do).
6.k/3 To be honest: The exclusion of variables from renamed object_names
is not enough to prevent altering the value of the name or
expression by another access path. For instance, both in
parameters passed by reference and access-to-constant values can
designate variables. For the intended use of "known to be the same
object", this is OK; the modification via another access path is
very tricky and it is OK to reject code that would be buggy except
for the tricky code. Assuming Element is an elementary type,
consider the following example:
6.l/3 Global : Tagged_Type;
6.m/3 procedure Foo (Param : in Tagged_Type := Global) is
X : Element renames Some_Global_Array (Param.C);
begin
Global.C := Global.C + 1;
Swap (X, Some_Global_Array (Param.C));
6.n/3 The rules will flag the call of procedure Swap as illegal, since X
and Some_Global_Array (Parameter.C) are known to denote the same
object (even though they will actually represent different objects
if Param = Global). But this is only incorrect if the parameter
actually is Global and not some other value; the error could exist
for some calls. So this flagging seems harmless.
6.o/3 Similar examples can be constructed using stand-alone composite
constants with controlled or immutably limited components, and (as
previously noted) with dereferences of access-to-constant values.
Even when these examples flag a call incorrectly, that call
depends on very tricky code (modifying the value of a constant);
the code is likely to confuse future maintainers as well and thus
we do not mind rejecting it.
6.p/3 Discussion: Whether or not names or prefixes are known to denote
the same object is determined statically. If the name contains
some dynamic portion other than a dereference, indexed_component,
or slice, it is not "known to denote the same object".
6.q/3 These rules make no attempt to handle slices of objects that are
known to be the same when the slices have dynamic bounds (other
than the trivial case of bounds being defined by the same
subtype), even when the bounds could be proven to be the same, as
it is just too complex to get right and these rules are intended
to be conservative.
6.r/3 Ramification: "Known to denote the same object" is intended to be
an equivalence relationship, that is, it is reflexive, symmetric,
and transitive. We believe this follows from the rules. For
instance, given the following declarations:
6.s/3 S : String(1..10);
ONE : constant Natural := 1;
R : Character renames S(1);
6.t/3 the names R and S(1) are known to denote the same object by the
sixth bullet, and S(1) and S(ONE) are known to denote the same
object by the fourth bullet, so using the sixth bullet on R and
S(ONE), we simply have to test S(1) vs. S(ONE), which we already
know denote the same object.
6.12/3 {AI05-0144-2} Two names are known to refer to the same object if
6.13/3 * The two names are known to denote the same object; or
6.14/3 * One of the names is a selected_component, indexed_component, or
slice and its prefix is known to refer to the same object as the other
name; or
6.15/3 * One of the two names statically denotes a renaming declaration
whose renamed object_name is known to refer to the same object as the
other name.
6.u/3 Reason: This ensures that names Prefix.Comp and Prefix are known
to refer to the same object for the purposes of the rules below.
This intentionally does not include dereferences; we only want to
worry about accesses to the same object, and a dereference changes
the object in question. (There is nothing shared between an access
value and the object it designates.)
6.16/3 {AI05-0144-2} If a call C has two or more parameters of mode in out or
out that are of an elementary type, then the call is legal only if:
6.17/3 * For each name N that is passed as a parameter of mode in out or out
to the call C, there is no other name among the other parameters of
mode in out or out to C that is known to denote the same object.
6.v/3 To be honest: This means visibly an elementary type; it does not
include partial views of elementary types (partial views are
always composite). That's necessary to avoid having
Legality Rules depend on the contents of the private part.
6.18/3 {AI05-0144-2} If a construct C has two or more direct constituents that
are names or expressions whose evaluation may occur in an arbitrary order, at
least one of which contains a function call with an in out or out parameter,
then the construct is legal only if:
6.w/3 Ramification: All of the places where the language allows an
arbitrary order can be found by looking in the index under
"arbitrary order, allowed". Note that this listing includes places
that don't involve names or expressions (such as checks or
finalization).
6.19/3 * For each name N that is passed as a parameter of mode in out or out
to some inner function call C2 (not including the construct C itself),
there is no other name anywhere within a direct constituent of the
construct C other than the one containing C2, that is known to refer
to the same object.
6.x/3 Ramification: This requirement cannot fail for a procedure or
entry call alone; there must be at least one function with an in
out or out parameter called as part of a parameter expression of
the call in order for it to fail.
6.y/3 Reason: These rules prevent obvious cases of dependence on the
order of evaluation of names or expressions. Such dependence is
usually a bug, and in any case, is not portable to another
implementation (or even another optimization setting).
6.z/3 In the case that the top-level construct C is a call, these rules
do not require checks for most in out parameters, as the rules
about evaluation of calls prevent problems. Similarly, we do not
need checks for short circuit operations or other operations with
a defined order of evaluation. The rules about arbitrary order
(see 1.1.4) allow evaluating parameters and writing parameters
back in an arbitrary order, but not interleaving of evaluating
parameters of one call with writing parameters back from another -
that would not correspond to any allowed sequential order.
6.20/3 {AI05-0144-2} For the purposes of checking this rule:
6.21/3 * For an array aggregate, an expression associated with a
discrete_choice_list that has two or more discrete choices, or that
has a nonstatic range, is considered as two or more separate
occurrences of the expression;
6.22/3 * For a record aggregate:
6.23/3 * The expression of a record_component_association is considered to
occur once for each associated component; and
6.24/3 * The default_expression for each record_component_association with
<> for which the associated component has a default_expression is
considered part of the aggregate;
6.25/3 * For a call, any default_expression evaluated as part of the call is
considered part of the call.
6.aa/3 Ramification: We do not check expressions that are evaluated only
because of a component initialized by default in an aggregate (via
<>).
Dynamic Semantics
7 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.
10.a Discussion: We are always allowing sliding, even for [in] out
by-reference parameters.
11 * 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.
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/3 * {AI05-0153-3} {AI05-0196-1} For an access type, the formal
parameter is initialized from the value of the actual, without
checking that the value satisfies any constraint, any predicate,
or any exclusion of the null value;
13.a Reason: This preserves the Language Design Principle that an
object of an access type is always initialized with a "
reasonable" value.
13.1/4 * {AI05-0153-3} {AI05-0228-1} {AI12-0074-1} {AI12-0159-1} For a
scalar type that has the Default_Value aspect specified, the
formal parameter is initialized from the value of the actual,
without checking that the value satisfies any constraint or any
predicate. Furthermore, if the actual parameter is a view
conversion and either
13.2/4 * {AI12-0074-1} there exists no type (other than a root numeric
type) that is an ancestor of both the target type and the type
of the operand of the conversion; or
13.3/4 * {AI12-0074-1} the Default_Value aspect is unspecified for the
type of the operand of the conversion
13.4/4 {AI12-0074-1} then Program_Error is raised;
13.b/3 Reason: This preserves the Language Design Principle that all
objects of a type with an implicit initial value are initialized.
This is important so that a programmer can guarantee that all
objects of a scalar type have a valid value with a carefully
chosen Default_Value.
13.c/3 Implementation Note: This rule means that out parameters of a
subtype T with a specified Default_Value need to be large enough
to support any possible value of the base type of T. In contrast,
a type that does not have a Default_Value only need support the
size of the subtype (since no values are passed in).
13.d/4 Discussion: The Program_Error case can only occur in the body of
an instance of a generic unit. Legality Rules will catch all other
cases. Implementations that macro-expand generics can always
detect this case when the enclosing instance body is expanded.
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/3 Ramification: {AI05-0228-1} This case covers scalar types that do
not have Default_Value specified, 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.
15.1/3 * {AI05-0142-4} {AI05-0234-1} In a function call, for each explicitly
aliased parameter, a check is made that the accessibility level of the
master of the actual object is not deeper than that of the master of
the call (see 3.10.2).
15.a.1/3 Ramification: If the actual object to a call C is a formal
parameter of some function call F, no dynamic check against the
master of the actual parameter of F is necessary. Any case which
could fail the dynamic check is already statically illegal (either
at the call site of F, or at the call site C). This is important,
as it would require nasty distributed overhead to accurately know
the dynamic accessibility of a formal parameter (all tagged and
explicitly aliased parameters would have to carry accessibility
levels).
16 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 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. 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.
Erroneous Execution
18/3 {AI05-0008-1} If the nominal subtype of a formal parameter with
discriminants is constrained or indefinite, and the parameter is passed by
reference, then the execution of the call is erroneous if the value of any
discriminant of the actual is changed while the formal parameter exists (that
is, before leaving the corresponding callable construct).
Extensions to Ada 83
18.a 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
18.b/3 {AI05-0299-1} We have eliminated the subclause on Default
Parameters, as it is subsumed by earlier subclauses.
Inconsistencies With Ada 2005
18.c/3 {AI05-0196-1} Correction: Clarified that out parameters of an
access type are not checked for null exclusions when they are
passed in (which is similar to the behavior for constraints). This
was unspecified in Ada 2005, so a program which depends on the
behavior of an implementation which does check the exclusion may
malfunction. But a program depending on an exception being raised
is unlikely.
Incompatibilities With Ada 2005
18.d/3 {AI05-0144-2} Additional rules have been added to make illegal
passing the same elementary object to more than one in out or out
parameters of the same call. In this case, the result in the
object could depend on the compiler version, optimization
settings, and potentially the phase of the moon, so this check
will mostly reject programs that are nonportable and could fail
with any change. Even when the result is expected to be the same
in both parameters, the code is unnecessarily tricky. Programs
which fail this new check should be rare and are easily fixed by
adding a temporary object.
Wording Changes from Ada 2005
18.e/3 {AI05-0008-1} Correction: A missing rule was added to cover cases
that were missed in Ada 95 and Ada 2005; specifically, that an in
parameter passed by reference might have its discriminants changed
via another path. Such cases are erroneous as requiring compilers
to detect such errors would be expensive, and requiring such cases
to work would be a major change of the user model (in parameters
with discriminants could no longer be assumed constant). This is
not an inconsistency, as compilers are not required to change any
current behavior.
18.f/3 {AI05-0102-1} Correction: Moved implicit conversion
Legality Rule to 8.6.
18.g/3 {AI05-0118-1} Correction: Added a definition for positional
parameters, as this is missing from Ada 95 and later.
18.h/3 {AI05-0142-4} Rules have been added defining the legality and
dynamic checks needed for explicitly aliased parameters (see 6.1).
18.i/3 {AI05-0144-2} Additional rules have been added such that passing
an object to an in out or out parameter of a function is illegal
if it is used elsewhere in a construct which allows evaluation in
an arbitrary order. Such calls are not portable (since the results
may depend on the evaluation order), and the results could even
vary because of optimization settings and the like. Thus they've
been banned.
Incompatibilities With Ada 2012
18.j/4 {AI12-0074-1} {AI12-0159-1} Corrigendum: Added rules to ensure
that the value passed into a out parameter for elementary types is
well-defined in the case of a view conversion. The new rules can
be incompatible. For a view conversion to an unrelated type with
the Default_Value aspect specified, the aspect is new in Ada 2012
so it should be unlikely to occur in existing code. For a view
conversion to an unrelated access type, the incompatibility is
possible as this could be written in Ada 95, but such a view
conversion is thought to be rare. In both cases, declaring and
passing a temporary rather than a view conversion will eliminate
the problem.
18.k/4 {AI12-0095-1} Corrigendum: Because of a rule added in 12.5.1, the
checks for the passing of an object to an explicitly aliased
parameter in a generic body were strengthened to use an assume the
worst rule. This case is rather unlikely as a formal private or
derived type with discriminants is required along with an
explicitly aliased parameter whose type doesn't statically match
the formal type. Such a program is very unlikely, especially as
explicitly aliased parameters are a new Ada 2012 feature.
6.5 Return Statements
1/2 {AI95-00318-02} A simple_return_statement or extended_return_statement
(collectively called a return statement) is used to complete the execution of
the innermost enclosing subprogram_body, entry_body, or accept_statement.
Syntax
2/2 {AI95-00318-02} simple_return_statement ::= return [expression];
2.1/3 {AI05-0277-1} extended_return_object_declaration ::=
defining_identifier
: [aliased][constant] return_subtype_indication [:= expression]
2.2/3 {AI95-00318-02} {AI05-0015-1} {AI05-0053-1} {AI05-0277-1}
{AI05-0299-1} extended_return_statement ::=
return extended_return_object_declaration [do
handled_sequence_of_statements
end return];
2.3/2 {AI95-00318-02} return_subtype_indication ::= subtype_indication
| access_definition
Name Resolution Rules
3/2 {AI95-00318-02} The result subtype of a function is the subtype denoted by
the subtype_mark, or defined by the access_definition, after the reserved word
return in the profile of the function. The expected type for the expression,
if any, of a simple_return_statement is the result type of the corresponding
function. The expected type for the expression of an
extended_return_statement is that of the return_subtype_indication.
3.a To be honest: The same applies to generic functions.
Legality Rules
4/2 {AI95-00318-02} A return statement shall be within a callable construct,
and it applies to the innermost callable construct or
extended_return_statement that contains it. A return statement shall not be
within a body that is within the construct to which the return statement
applies.
4.a/4 To be honest: {AI12-0089-1} The above also applies to generic
subprograms, even though they are not callable constructs. (An
instance of a generic subprogram is a callable construct, but not
a generic subprogram itself.)
5/3 {AI95-00318-02} {AI05-0015-1} A function body shall contain at least one
return statement that applies to the function body, unless the function
contains code_statements. A simple_return_statement shall include an
expression if and only if it applies to a function body. An
extended_return_statement shall apply to a function body. An
extended_return_statement with the reserved word constant shall include an
expression.
5.a/4 Reason: {AI95-00318-02} {AI12-0022-1} The requirement that a
function body has to have at least one return statement is a "
helpful" restriction. There has been some interest in lifting this
restriction, or allowing a raise statement to substitute for the
return statement. However, there was enough interest in leaving it
as is that we decided not to change it. Note that for Ada 2012,
Corrigendum 1, a return statement whose expression is a
raise_expression can be given in any function body (the
raise_expression will match any type), so there is much less need
to eliminate this rule.
5.b/2 Ramification: {AI95-00318-02} A return statement can apply to an
extended_return_statement, so a simple_return_statement without an
expression can be given in one. However, neither simple_return_-
statement with an expression nor an extended_return_statement can
be given inside an extended_return_statement, as they must apply
(directly) to a function body.
5.b.1/4 {AI12-0089-1} Since a "function body" includes a generic function
body, this rule and all of the following Legality Rules apply to
generic function bodies as well as non-generic function bodies.
This is true even though a generic function is not a function.
5.1/2 {AI95-00318-02} For an extended_return_statement that applies to a
function body:
5.2/3 * {AI95-00318-02} {AI05-0032-1} {AI05-0103-1} If the result subtype of
the function is defined by a subtype_mark, the
return_subtype_indication shall be a subtype_indication. The type of
the subtype_indication shall be covered by the result type of the
function. The subtype defined by the subtype_indication shall be
statically compatible with the result subtype of the function; if the
result type of the function is elementary, the two subtypes shall
statically match. If the result subtype of the function is indefinite,
then the subtype defined by the subtype_indication shall be a definite
subtype, or there shall be an expression.
5.3/2 * {AI95-00318-02} If the result subtype of the function is defined by
an access_definition, the return_subtype_indication shall be an
access_definition. The subtype defined by the access_definition shall
statically match the result subtype of the function. [The
accessibility level of this anonymous access subtype is that of the
result subtype.]
5.b.2/4 Proof: {AI12-0070-1} The accessibility of such anonymous access
types is defined in the Heart of Darkness (aka 3.10.2).
5.4/3 * {AI05-0032-1} If the result subtype of the function is class-wide,
the accessibility level of the type of the subtype defined by the
return_subtype_indication shall not be statically deeper than that of
the master that elaborated the function body.
5.b.3/3 Reason: In this case, the return_subtype_indication could be a
specific type initialized by default; in that case there is no
expression to check.
5.5/3 {AI95-00318-02} {AI05-0032-1} For any return statement that applies to a
function body:
5.6/3 * {AI95-00318-02} {AI05-0188-1} [If the result subtype of the function
is limited, then the expression of the return statement (if any) shall
meet the restrictions described in 7.5.]
5.c/3 This paragraph was deleted.{AI05-0188-1}
5.7/3 * {AI95-00416-01} {AI05-0032-1} {AI05-0051-1} If the result subtype of
the function is class-wide, the accessibility level of the type of the
expression (if any) of the return statement shall not be statically
deeper than that of the master that elaborated the function body.
5.d/4 Discussion: {AI05-0032-1} {AI05-0051-1} {AI12-0005-1} If the
result type is class-wide, then there must be an expression of the
return statement unless this is an extended_return_statement whose
return_subtype_indication is a specific type. We have a separate
rule to cover that case. Note that if an
extended_return_statement has an expression, then both this rule
and the next one must be satisfied.
5.8/3 * {AI05-0051-1} If the subtype determined by the expression of the
simple_return_statement or by the return_subtype_indication has one or
more access discriminants, the accessibility level of the anonymous
access type of each access discriminant shall not be statically deeper
than that of the master that elaborated the function body.
5.d.1/3 Discussion: We use the type used by the return statement rather
than from the function return type since we want to check whenever
the return object has access discriminants, even if the function
return type doesn't have any (mostly for a class-wide type).
5.9/3 {AI05-0277-1} If the keyword aliased is present in an
extended_return_object_declaration, the type of the extended return object
shall be immutably limited.
Static Semantics
5.10/3 {AI95-00318-02} {AI05-0015-1} {AI05-0144-2} Within an
extended_return_statement, the return object is declared with the given
defining_identifier, with the nominal subtype defined by the return_subtype_-
indication. An extended_return_statement with the reserved word constant is a
full constant declaration that declares the return object to be a constant
object.
Dynamic Semantics
5.11/3 {AI95-00318-02} {AI95-00416-01} {AI05-0032-1} For the execution of an
extended_return_statement, the subtype_indication or access_definition is
elaborated. This creates the nominal subtype of the return object. If there is
an expression, it is evaluated and converted to the nominal subtype (which
might raise Constraint_Error - see 4.6); the return object is created and the
converted value is assigned to the return object. Otherwise, the return object
is created and initialized by default as for a stand-alone object of its
nominal subtype (see 3.3.1). If the nominal subtype is indefinite, the return
object is constrained by its initial value. A check is made that the value of
the return object belongs to the function result subtype. Constraint_Error is
raised if this check fails.
5.e/2 Ramification: If the result type is controlled or has a controlled
part, appropriate calls on Initialize or Adjust are performed
prior to executing the handled_sequence_of_statements, except when
the initial expression is an aggregate (which requires
build-in-place with no call on Adjust).
5.f/3 {AI05-0005-1} If the return statement is left without resulting in
a return (for example, due to an exception propagated from the
expression or the handled_sequence_of_statements, or a goto out of
the handled_sequence_of_statements), if the return object has been
created, it is finalized prior to leaving the return statement. If
it has not been created when the return statement is left, it is
not created or finalized.
5.g/3 {AI05-0032-1} Other rules ensure that the check required by this
rule cannot fail unless the function has a class-wide result
subtype where the associated specific subtype is constrained. In
other cases, either the subtypes have to match or the function's
subtype is unconstrained and needs no checking.
6/2 {AI95-00318-02} For the execution of a simple_return_statement, the
expression (if any) is first evaluated, converted to the result subtype, and
then is assigned to the anonymous return object.
6.a Ramification: The conversion might raise Constraint_Error - (see
4.6).
7/2 {AI95-00318-02} {AI95-00416-01} [If the return object has any parts that
are tasks, the activation of those tasks does not occur until after the
function returns (see 9.2).]
7.a/2 Proof: This is specified by the rules in 9.2.
7.b/2 Reason: Only the caller can know when task activations should take
place, as it depends on the context of the call. If the function
is being used to initialize the component of some larger object,
then that entire object must be initialized before any task
activations. Even after the outer object is fully initialized,
task activations are still postponed until the begin at the end of
the declarative part if the function is being used to initialize
part of a declared object.
8/4 {AI95-00318-02} {AI95-00344-01} {AI05-0024-1} {AI05-0032-1} {AI12-0097-1}
If the result type of a function is a specific tagged type, the tag of the
return object is that of the result type. If the result type is class-wide,
the tag of the return object is that of the value of the expression, unless
the return object is defined by an extended_return_object_declaration with a
subtype_indication that is specific, in which case it is that of the type of
the subtype_indication. A check is made that the master of the type identified
by the tag of the result includes the elaboration of the master that
elaborated the function body. If this check fails, Program_Error is raised.
8.a/2 Ramification: {AI95-00318-02} The first sentence is true even if
the tag of the expression is different, which could happen if the
expression were a view conversion or a dereference of an access
value. Note that for a limited type, because of the restriction to
aggregates and function calls (and no conversions), the tag will
already match.
8.b/2 Reason: {AI95-00318-02} The first rule ensures that a function
whose result type is a specific tagged type always returns an
object whose tag is that of the result type. This is important for
dispatching on controlling result, and allows the caller to
allocate the appropriate amount of space to hold the value being
returned (assuming there are no discriminants).
8.c/3 The master check prevents the returned object from outliving its
type. Note that this check cannot fail for a specific tagged type,
as the tag represents the function's type, which necessarily must
be declared outside of the function.
8.d/3 We can't use the normal accessibility level "deeper than" check
here because we may have "incomparable" levels if the masters
belong to two different tasks. This can happen when an accept
statement calls a function declared in the enclosing task body,
and the function returns an object passed to it from the accept
statement, and this object was itself a parameter to the accept
statement.
8.d.1/4 To be honest: {AI12-0097-1} The expression here is the return
expression if the return statement is a simple_return_statement,
and the initializing expression of the
extended_return_object_declaration if the return statement is an
extended_return_statement (ignoring any inner
simple_return_statements, which necessarily cannot have an
expression, and any other expressions inside of the
extended_return_statement).
8.1/3 {AI05-0073-1} If the result subtype of the function is defined by an
access_definition designating a specific tagged type T, a check is made that
the result value is null or the tag of the object designated by the result
value identifies T. Constraint_Error is raised if this check fails.
8.e/3 Reason: This check is needed so that dispatching on controlling
access results works for tag-indeterminate functions. If it was
not made, it would be possible for such functions to return an
access to a descendant type, meaning the function could return an
object with a tag different than the one assumed by the
dispatching rules.
Paragraphs 9 through 20 were deleted.
21/3 {AI95-00318-02} {AI95-00402-01} {AI95-00416-01} {AI05-0051-1} If any part
of the specific type of the return object of a function (or coextension
thereof) has one or more access discriminants whose value is not constrained
by the result subtype of the function, a check is made that the accessibility
level of the anonymous access type of each access discriminant, as determined
by the expression or the return_subtype_indication of the return statement, is
not deeper than the level of the master of the call (see 3.10.2). If this
check fails, Program_Error is raised.
21.a/2 This paragraph was deleted.
21.b/2 Reason: The check prevents the returned object (for a nonlimited
type) from outliving the object designated by one of its
discriminants. The check is made on the values of the
discriminants, which may come from the return_subtype_indication
(if constrained), or the expression, but it is never necessary to
check both.
21.c/3 Implementation Note: {AI05-0234-1} The reason for saying "any part
of the specific type" is to simplify implementation. In the case
of class-wide result objects, this allows the testing of a simple
flag in the tagged type descriptor that indicates whether the
specific type has any parts with access discriminants. By basing
the test on the type of the object rather than the object itself,
we avoid concerns about whether subcomponents in variant parts and
of arrays (which might be empty) are present.
21.d/3 Discussion: {AI05-0234-1} For a function with a class-wide result
type, the access values that need to be checked are determined by
the tag of the return object. In order to implement this
accessibility check in the case where the tag of the result is not
known statically at the point of the return statement, an
implementation may need to somehow associate with the tag of a
specific tagged type an indication of whether the type has
unconstrained access discriminants (explicit or inherited) or has
any subcomponents with such discriminants. If an implementation is
already maintaining a statically initialized descriptor of some
kind for each specific tagged type, then an additional Boolean
could be added to this descriptor.
21.e/3 {AI05-0005-1} {AI05-0234-1} Note that the flag should only be
queried in the case where the result object might have access
discriminants that might have subtypes with "bad" accessibility
levels (as determined by the rules of 3.10.2 for determining the
accessibility level of the type of an access discriminant in the
expression or return_subtype_indication of a return statement).
21.f/3 Thus, in a case like
21.g/3 type Global is access T'Class;
function F (Ptr : Global) return T'Class is
begin
return Ptr.all;
end F;
21.h/3 there is no need for a run-time accessibility check. While an
object of T'Class "might have" access discriminants, the
accessibility of those potential discriminants cannot be bad. The
setting of the bit doesn't matter and there is no need to query it.
21.i/3 On the other hand, given
21.j/3 function F return T'Class is
Local : T'Class := ... ;
begin
return Local;
end F;
21.k/3 In this case, a check would typically be required.
21.l/3 The need for including subcomponents in this check is illustrated
by the following example:
21.m/3 X : aliased Integer;
21.n/3 type Component_Type (Discrim : access Integer := X'Access)
is limited null record;
21.o/3 type Undiscriminated is record
Fld : Component_Type;
end record;
21.p/3 function F return Undiscriminated is
Local : aliased Integer;
begin
return X : Undiscriminated := (Fld => (Discrim => Local'Access)) do
Foo;
end return;
-- raises Program_Error after calling Foo.
end F;
21.q/3 Ramification: {AI05-0234-1} In the case where the tag of the
result is not known statically at the point of the return
statement and the run-time accessibility check is needed,
discriminant values and array bounds play no role in performing
this check. That is, array components are assumed to have nonzero
length and components declared within variant parts are assumed to
be present. Thus, the check may be implemented simply by testing
the aforementioned descriptor bit and conditionally raising
Program_Error.
22/3 {AI95-00318-02} {AI05-0058-1} For the execution of an extended_return_-
statement, the handled_sequence_of_statements is executed. Within this handled_-
sequence_of_statements, the execution of a simple_return_statement that
applies to the extended_return_statement causes a transfer of control that
completes the extended_return_statement. Upon completion of a return statement
that applies to a callable construct by the normal completion of a simple_-
return_statement or by reaching the end return of an
extended_return_statement, a transfer of control is performed which completes
the execution of the callable construct, and returns to the caller.
22.a/3 Ramification: {AI05-0058-1} A transfer of control that completes
an extended_return_statement (such as an exit or goto) does not
cause a return to the caller unless it is caused by
simple_return_statement (that is, triggers the second sentence of
this paragraph). The return to the caller occurs for the
simple_return_statement that applies to an
extended_return_statement because the last sentence says "the
normal completion of a simple_return_statement", which includes
the one nested in the extended_return_statement.
23/2 {AI95-00318-02} In the case of a function, the function_call denotes a
constant view of the return object.
Implementation Permissions
24/3 {AI95-00416-01} {AI05-0050-1} For a function call used to initialize a
composite object with a constrained nominal subtype or used to initialize a
return object that is built in place into such an object:
24.1/3 * {AI05-0050-1} If the result subtype of the function is constrained,
and conversion of an object of this subtype to the subtype of the
object being initialized would raise Constraint_Error, then
Constraint_Error may be raised before calling the function.
24.2/3 * {AI05-0050-1} If the result subtype of the function is
unconstrained, and a return statement is executed such that the return
object is known to be constrained, and conversion of the return object
to the subtype of the object being initialized would raise
Constraint_Error, then Constraint_Error may be raised at the point of
the call (after abandoning the execution of the function body).
24.a/3 Reason: {AI95-00416-01} {AI05-0050-1} Without such a permission,
it would be very difficult to implement "built-in-place"
semantics. The intention is that the exception is raised at the
same point that it would have been raised without the permission;
it should not change handlers if the implementation switches
between return-by-copy and built-in-place. This means that the
exception is not handleable within the function, because in the
return-by-copy case, the constraint check to verify that the
result satisfies the constraints of the object being initialized
happens after the function returns. This implies further that upon
detecting such a situation, the implementation may need to
simulate a goto to a point outside any local exception handlers
prior to raising the exception.
24.b/3 Ramification: {AI95-00416-01} {AI05-0050-1} These permissions do
not apply in the case of an extended return object with mutable
discriminants. That's necessary because in that case a return
object can be created with the "wrong" discriminants and then
changed to the "right" discriminants later (but before returning).
We don't want this case raising an exception when the canonical
semantics will not do so.
24.c/3 {AI05-0050-1} It's still possible to write a program that will
raise an exception using this permission that would not in the
canonical semantics. That could happen if a return statement with
the "wrong" discriminants or bounds is abandoned (via an
exception, or for an extended_return_statement, via an exit or
goto statement), and then a return statement with the "right"
discriminants or bounds is executed. The only solution for this
problem is to not have the permission at all, but this is too
unusual of a case to worry about the effects of the permission,
especially given the implementation difficulties for
built-in-place objects that this permission is intended to ease.
24.d/3 {AI05-0050-1} Note that the mutable-discriminant case only happens
when built-in-place initialization is optional. This means that
any difficulties associated with implementing built-in-place
initialization without these permissions can be sidestepped by not
building in place.
Examples
25 Examples of return statements:
26/2 {AI95-00318-02}
return; -- in a procedure body, entry_body,
-- accept_statement
, or extended_return_statement
27 return Key_Value(Last_Index); -- in a function body
28/2 {AI95-00318-02}
return Node : Cell do -- in a function body, see 3.10.1
for Cell
Node.Value := Result;
Node.Succ := Next_Node;
end return;
Incompatibilities With Ada 83
28.a/2 {AI95-00318-02} In Ada 95, if the result type of a function has a
part that is a task, then an attempt to return a local variable
will raise Program_Error. This is illegal in Ada 2005, see below.
In Ada 83, if a function returns a local variable containing a
task, execution is erroneous according to AI83-00867. However,
there are other situations where functions that return tasks (or
that return a variant record only one of whose variants includes a
task) are correct in Ada 83 but will raise Program_Error according
to the new rules.
28.b The rule change was made because there will be more types
(protected types, limited controlled types) in Ada 95 for which it
will be meaningless to return a local variable, and making all of
these erroneous is unacceptable. The current rule was felt to be
the simplest that kept upward incompatibilities to situations
involving returning tasks, which are quite rare.
Wording Changes from Ada 83
28.c/3 {AI05-0299-1} This subclause has been moved here from chapter 5,
since it has mainly to do with subprograms.
28.d A function now creates an anonymous object. This is necessary so
that controlled types will work.
28.e/2 {AI95-00318-02} We have clarified that a return statement applies
to a callable construct, not to a callable entity.
28.f/2 {AI95-00318-02} There is no need to mention generics in the rules
about where a return statement can appear and what it applies to;
the phrase "body of a subprogram or generic subprogram" is
syntactic, and refers exactly to "subprogram_body".
Inconsistencies With Ada 95
28.f.1/3 {AI95-0416-1} {AI05-0005-1} {AI05-0050-1} Added an
Implementation Permission allowing early raising of
Constraint_Error if the result cannot fit in the ultimate object.
This gives implementations more flexibility to do built-in-place
returns, and is essential for limited types (which cannot be built
in a temporary). However, it allows raising Constraint_Error in
some cases where it would not be raised if the permission was not
used. See Inconsistencies With Ada 2005 for additional changes.
This case is potentially inconsistent with Ada 95, but a compiler
does not have to take advantage of these permissions for any Ada
95 code, so there should be little practical impact.
Incompatibilities With Ada 95
28.g/2 {AI95-00318-02} The entire business about return-by-reference
types has been dropped. Instead, the expression of a return
statement of a limited type can only be an aggregate or
function_call (see 7.5). This means that returning a global object
or type_conversion, legal in Ada 95, is now illegal. Such
functions can be converted to use anonymous access return types by
adding access in the function definition and return statement,
adding .all in uses, and adding aliased in the object
declarations. This has the advantage of making the reference
return semantics much clearer to the casual reader.
28.h/2 We changed these rules so that functions, combined with the new
rules for limited types (7.5), can be used as build-in-place
constructors for limited types. This reduces the differences
between limited and nonlimited types, which will make limited
types useful in more circumstances.
Extensions to Ada 95
28.i/2 {AI95-00318-02} The extended_return_statement is new. This
provides a name for the object being returned, which reduces the
copying needed to return complex objects (including no copying at
all for limited objects). It also allows component-by-component
construction of the return object.
Wording Changes from Ada 95
28.j/2 {AI95-00318-02} The wording was updated to support anonymous
access return subtypes.
28.k/2 {AI95-00318-02} The term "return expression" was dropped because
reviewers found it confusing when applied to the default
expression of an extended_return_statement.
28.l/2 {AI95-00344-01} {AI95-00416-01} Added accessibility checks to
class-wide return statements. These checks could not fail in Ada
95 (as all of the types had to be declared at the same level, so
the tagged type would necessarily have been at the same level as
the type of the object).
28.m/2 {AI95-00402-01} {AI95-00416-01} Added accessibility checks to
return statements for types with access discriminants. Since such
types have to be limited in Ada 95, the expression of a return
statement would have been illegal in order for this check to fail.
Inconsistencies With Ada 2005
28.n/3 {AI05-0050-1} Correction: The Implementation Permission allowing
early raising of Constraint_Error was modified to remove the most
common of these cases from the permission (returning an object
with mutable discriminants, where the return object is created
with one set of discriminants and then changed to another). (The
permission was also widened to allow the early check for
constrained functions when that constraint is wrong.) However,
there still is an unlikely case where the permission would allow
an exception to be raised when none would be raised by the
canonical semantics (when a return statement is abandoned). These
changes can only remove the raising of an exception (or change the
place where it is raised) compared to Ada 2005, so programs that
depend on the previous behavior should be very rare.
28.o/3 {AI05-0051-1} {AI05-0234-1} Correction: Accessibility checks for
access discriminants now depend on the master of the call rather
than the point of declaration of the function. This will result in
cases that used to raise Program_Error now running without raising
any exception. This is technically inconsistent with Ada 2005 (as
defined by Amendment 1), but it is unlikely that any real code
depends on the raising of this exception.
28.p/3 {AI05-0073-1} Correction: Added a tag check for functions
returning anonymous access-to-tagged types, so that dispatching of
tag-indeterminate function works as expected. This is technically
inconsistent with Ada 2005 (as defined by Amendment 1), but as the
feature in question was newly added to Ada 2005, there should be
little code that depends on the behavior that now raises an
exception.
Incompatibilities With Ada 2005
28.q/3 {AI05-0053-1} {AI05-0277-1} Correction: The aliased keyword can
now only appear on extended return objects with an immutably
limited type. Other types would provide a way to get an aliased
view of an object that is not necessarily aliased, which would be
very bad. This is incompatible, but since the feature was added in
Ada 2005, the keyword had no defined meaning in Ada 2005 (a
significant oversight), and most sensible uses involve immutably
limited types, it is unlikely that it appears meaningfully in
existing programs.
28.r/3 {AI05-0103-1} Correction: Added wording to require static matching
for unconstrained access types in extended return statements. This
disallows adding or omitting null exclusions, and adding access
constraints, in the declaration of the return object. While this
is incompatible, the incompatible cases in question are either
useless (access constraints - the constraint can be given on an
allocator if necessary, and still must be given there even if
given on the return object) or wrong (null exclusions - null could
be returned from a function declared to be null excluding), so we
expect them to be extremely rare in practice.
Extensions to Ada 2005
28.s/3 {AI05-0015-1} {AI05-0144-2} The return object of an
extended_return_statement can be declared constant; this works
similarly to a constant object declaration.
28.t/3 {AI05-0032-1} Added wording to allow the
return_subtype_indication to have a specific type if the return
subtype of the function is class-wide. Specifying the (specific)
type of the return object is awkward without this change, and this
is consistent with the way allocators work.
Wording Changes from Ada 2005
28.u/3 {AI05-0024-1} Correction: Corrected the master check for tags
since the masters may be for different tasks and thus incomparable.
28.v/3 {AI05-0058-1} Correction: Corrected the wording defining returns
for extended_return_statements, since leaving by an exit or goto
is considered "normal" completion of the statement.
28.w/3 {AI05-0205-1} {AI05-0277-1} Correction: Added the
extended_return_object_declaration to make other rules easier to
write and eliminate the problem described in AI05-0205-1.
Wording Changes from Ada 2012
28.x/4 {AI05-0097-1} Corrigendum: Clarified the wording so that it is
clear where the tag of the return object comes from. While a
literal reading of the original Ada 2012 rule could have caused
some weird results (by using some nearby subtype_indication to
provide the tag in the case of a simple_return_statement, such a
reading would be so unlike the rest of the language that we do not
believe anyone would ever have thought it was intended. As such,
we do not believe any implementation ever did this wrong (at least
because of the old wording), and thus do not document this as a
possible inconsistency.
6.5.1 Nonreturning Procedures
1/3 {AI95-00329-01} {AI95-00414-01} {AI05-0229-1} Specifying aspect No_Return
to have the value True indicates that a procedure cannot return normally[; it
may propagate an exception or loop forever].
1.a/3 Discussion: Aspect No_Deposit will have to wait for Ada 2020. :-)
Paragraphs 2 and 3 were moved to Annex J, "Obsolescent Features".
Static Semantics
3.1/3 {AI05-0229-1} For a procedure or generic procedure, the following
language-defined representation aspect may be specified:
3.2/3 No_Return The type of aspect No_Return is Boolean. When aspect No_Return
is True for an entity, the entity is said to be nonreturning.
3.3/3 If directly specified, the aspect_definition shall be a static
expression. [This aspect is never inherited;] if not directly
specified, the aspect is False.
3.a/3 Aspect Description for No_Return: A procedure will not return
normally.
3.4/3 {AI05-0229-1} If a generic procedure is nonreturning, then so are its
instances. If a procedure declared within a generic unit is nonreturning, then
so are the corresponding copies of that procedure in instances.
Legality Rules
4/3 {AI95-00329-01} {AI95-00414-01} {AI05-0229-1} Aspect No_Return shall not
be specified for a null procedure nor an instance of a generic unit.
4.a/2 Reason: A null procedure cannot have the appropriate nonreturning
semantics, as it does not raise an exception or loop forever.
4.b/3 Ramification: {AI05-0229-1} The procedure can be abstract. If a
nonreturning procedure is renamed (anywhere) calls through the new
name still have the nonreturning semantics.
5/2 {AI95-00329-01} {AI95-00414-01} A return statement shall not apply to a
nonreturning procedure or generic procedure.
6/2 {AI95-00414-01} A procedure shall be nonreturning if it overrides a
dispatching nonreturning procedure. 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.
6.a/2 Reason: This ensures that dispatching calls to nonreturning
procedures will, in fact, not return.
7/2 {AI95-00414-01} If a renaming-as-body completes a nonreturning procedure
declaration, then the renamed procedure shall be nonreturning.
7.a/2 Reason: This ensures that no extra code is needed to implement the
renames (that is, no wrapper is needed) as the body has the same
property.
Paragraph 8 was deleted.
Dynamic Semantics
9/2 {AI95-00329-01} {AI95-00414-01} If the body of a nonreturning procedure
completes normally, Program_Error is raised at the point of the call.
9.a/2 Discussion: Note that there is no name for suppressing this check,
since the check represents a bug, imposes no time overhead, and
minimal space overhead (since it can usually be statically
eliminated as dead code).
9.b/2 Implementation Note: If a nonreturning procedure tries to return,
we raise Program_Error. This is stated as happening at the call
site, because we do not wish to allow the procedure to handle the
exception (and then, perhaps, try to return again!). However, the
expected run-time model is that the compiler will generate raise
Program_Error at the end of the procedure body (but not handleable
by the procedure itself), as opposed to doing it at the call site.
(This is just like the typical run-time model for functions that
fall off the end without returning a value). The reason is
indirect calls: in P.all(...);, the compiler cannot know whether P
designates a nonreturning procedure or a normal one. Putting the
raise Program_Error in the procedure's generated code solves this
problem neatly.
9.c/2 Similarly, if one passes a nonreturning procedure to a generic
formal parameter, the compiler cannot know this at call sites (in
shared code implementations); the raise-in-body solution deals
with this neatly.
Examples
10/3 {AI95-00433-01} {AI05-0229-1}
procedure Fail(Msg : String) -- raises Fatal_Error exception
with No_Return;
-- Inform compiler and reader that procedure never returns normally
Extensions to Ada 95
10.a/2 {AI95-00329-01} {AI95-00414-01} Pragma No_Return is new.
Extensions to Ada 2005
10.b/3 {AI05-0229-1} Aspect No_Return is new; pragma No_Return is now
obsolescent.
6.6 Overloading of Operators
1 An operator is a function whose designator is an operator_symbol.
[Operators, like other functions, may be overloaded.]
Name Resolution Rules
2 Each use of a unary or binary operator is equivalent to a function_call
with function_prefix being the corresponding operator_symbol, and with
(respectively) one or two positional actual parameters being the operand(s) of
the operator (in order).
2.a/3 To be honest: {AI05-0299-1} We also use the term operator (in
Clause 4 and in 6.1) to refer to one of the syntactic categories
defined in 4.5, "Operators and Expression Evaluation" whose names
end with "_operator:" logical_operator, relational_operator,
binary_adding_operator, unary_adding_operator, multiplying_-
operator, and highest_precedence_operator.
2.b/3 Discussion: {AI05-0005-1} This equivalence extends to uses of
function_call in most other language rules. However, as often
happens, the equivalence is not perfect, as operator calls are not
a name, while a function_call is a name. Thus, operator calls
cannot be used in contexts that require a name (such as a rename
of an object). A direct fix for this problem would be very
disruptive, and thus we have not done that. However, qualifying an
operator call can be used as a workaround in contexts that require
a name.
Legality Rules
3/3 {AI05-0143-1} The subprogram_specification of a unary or binary operator
shall have one or two parameters, respectively. The parameters shall be of
mode in. A generic function instantiation whose designator is an
operator_symbol is only allowed if the specification of the generic function
has the corresponding number of parameters, and they are all of mode in.
4 Default_expressions are not allowed for the parameters of an operator
(whether the operator is declared with an explicit subprogram_specification or
by a generic_instantiation).
5 An explicit declaration of "/=" shall not have a result type of the
predefined type Boolean.
Static Semantics
6/3 {AI05-0128-1} An explicit declaration of "=" whose result type is Boolean
implicitly declares an operator "/=" that gives the complementary result.
6.a/3 Discussion: {AI05-0128-1} A "/=" defined by this rule is
considered user-defined, which means that it will be inherited by
a derived type. "User-defined" means "not language-defined" for
the purposes of inheritance, that is anything other than
predefined operators.
NOTES
7 10 The operators "+" and "-" are both unary and binary operators, and
hence may be overloaded with both one- and two-parameter functions.
Examples
8 Examples of user-defined operators:
9 function "+" (Left, Right : Matrix) return Matrix;
function "+" (Left, Right : Vector) return Vector;
-- assuming that A, B, and C are of the type Vector
-- the following two statements are equivalent:
A := B + C;
A := "+"(B, C);
Extensions to Ada 83
9.a Explicit declarations of "=" are now permitted for any combination
of parameter and result types.
9.b Explicit declarations of "/=" are now permitted, so long as the
result type is not Boolean.
Wording Changes from Ada 2005
9.c/3 {AI05-0128-1} Correction: Corrected the wording so that only
explicit declarations of "=" cause an implicit declaration of
"/="; otherwise, we could get multiple implicit definitions of
"/=" without an obvious way to chose between them.
9.d/3 {AI05-0143-1} Added wording so that operators only allow
parameters of mode in. This was made necessary by the elimination
elsewhere of the restriction that function parameters be only of
mode in.
6.7 Null Procedures
1/2 {AI95-00348-01} A null_procedure_declaration provides a shorthand to
declare a procedure with an empty body.
Syntax
2/3 {AI95-00348-01} {AI05-0183-1} null_procedure_declaration ::=
[overriding_indicator]
procedure_specification is null
[aspect_specification];
Legality Rules
2.1/3 {AI05-0177-1} If a null_procedure_declaration is a completion, it shall
be the completion of a subprogram_declaration or
generic_subprogram_declaration. The profile of a null_procedure_declaration
that completes a declaration shall conform fully to that of the declaration.
Static Semantics
3/3 {AI95-00348-01} {AI05-0177-1} {AI05-0264-1} A null_procedure_declaration
declares a null procedure. A completion is not allowed for a
null_procedure_declaration; however, a null_procedure_declaration can complete
a previous declaration.
3.a/2 Reason: There are no null functions because the return value has
to be constructed somehow; a function that always raises
Program_Error doesn't seem very useful or worth the complication.
Dynamic Semantics
4/2 {AI95-00348-01} The execution of a null procedure is invoked by a
subprogram call. For the execution of a subprogram call on a null procedure,
the execution of the subprogram_body has no effect.
4.a/2 Ramification: Thus, a null procedure is equivalent to the body
4.b/2 begin
null;
end;
4.c/2 with the exception that a null procedure can be used in place of a
procedure specification.
5/3 {AI95-00348-01} {AI05-0177-1} The elaboration of a
null_procedure_declaration has no other effect than to establish that the null
procedure can be called without failing the Elaboration_Check.
Examples
6/2 {AI95-00433-01}
procedure Simplify(Expr : in out Expression) is null; -- see 3.9
-- By default, Simplify does nothing, but it may be overridden in extensions of Expression
Extensions to Ada 95
6.a/2 {AI95-00348-01} Null procedures are new.
Extensions to Ada 2005
6.b/3 {AI05-0177-1} A null_procedure_declaration can now be a completion.
6.c/3 {AI05-0183-1} An optional aspect_specification can be used in a
null_procedure_declaration. This is described in 13.1.1.
6.8 Expression Functions
1/3 {AI05-0177-1} An expression_function_declaration provides a shorthand to
declare a function whose body consists of a single return statement.
Syntax
2/4 {AI95-0177-1} {AI95-0147-1} expression_function_declaration ::=
[overriding_indicator]
function_specification is
(expression)
[aspect_specification];
| [overriding_indicator]
function_specification is
aggregate
[aspect_specification];
Name Resolution Rules
3/4 {AI05-0177-1} {AI95-0147-1} The expected type for the expression or
aggregate of an expression_function_declaration is the result type (see 6.5)
of the function.
Legality Rules
4/3 {AI05-0177-1} If an expression_function_declaration is a completion, it
shall be the completion of a subprogram_declaration or
generic_subprogram_declaration. The profile of an
expression_function_declaration that completes a declaration shall conform
fully to that of the declaration.
5/4 {AI05-0177-1} {AI95-0147-1} If the result subtype has one or more
unconstrained access discriminants, the accessibility level of the anonymous
access type of each access discriminant, as determined by the expression or
aggregate of the expression_function_declaration, shall not be statically
deeper than that of the master that elaborated the expression_function_-
declaration.
5.a/3 Ramification: This can only fail if the discriminant is an access
to a part of a non-aliased parameter, as there can be no local
declarations here.
5.b/4 Discussion: {AI12-0005-1} We don't need to repeat any of the other
Legality Rules for return statements since none of them can fail
here: the implicit return statement has to apply to this function
(and isn't nested in something), there clearly is a return
statement in this function, and the static class-wide
accessibility check cannot fail as a tagged type cannot be
declared locally in an expression function.
Static Semantics
6/4 {AI05-0177-1} {AI05-0264-1} {AI95-0147-1} An
expression_function_declaration declares an expression function. The return
expression of an expression function is the expression or aggregate of the
expression_function_declaration. A completion is not allowed for an expression_-
function_declaration; however, an expression_function_declaration can complete
a previous declaration.
Dynamic Semantics
7/4 {AI05-0177-1} {AI05-0262-1} {AI95-0147-1} The execution of an expression
function is invoked by a subprogram call. For the execution of a subprogram
call on an expression function, the execution of the subprogram_body executes
an implicit function body containing only a simple_return_statement whose
expression is the return expression of the expression function.
7.a/3 Discussion: The last sentence effectively means that all of the
dynamic wording in 6.5 applies as needed, and we don't have to
repeat it here.
8/3 {AI05-0177-1} The elaboration of an expression_function_declaration has no
other effect than to establish that the expression function can be called
without failing the Elaboration_Check.
Examples
9/3 {AI05-0177-1}
function Is_Origin (P : in Point) return Boolean is -- see 3.9
(P.X = 0.0 and P.Y = 0.0);
Extensions to Ada 2005
9.a/3 {AI05-0177-1} Expression functions are new in Ada 2012.
Extensions to Ada 2012
9.b/4 {AI12-0157-1} A aggregate can directly be the return expression of
an expression function. This eliminates the double parentheses
that otherwise would be necessary.
Generated by dwww version 1.15 on Mon Jun 24 14:18:50 CEST 2024.