5 Statements
1 [A statement defines an action to be performed upon its execution.]
2/3 {AI95-00318-02} {AI05-0299-1} [This clause describes the general rules
applicable to all statements. Some statements are discussed in later clauses:
Procedure_call_statements and return statements are described in 6, "
Subprograms". Entry_call_statements, requeue_statements, delay_statements,
accept_statements, select_statements, and abort_statements are described in
9, "Tasks and Synchronization". Raise_statements are described in 11, "
Exceptions", and code_statements in 13. The remaining forms of statements are
presented in this clause.]
Wording Changes from Ada 83
2.a/2 {AI95-00318-02} The description of return statements has been
moved to 6.5, "Return Statements", so that it is closer to the
description of subprograms.
5.1 Simple and Compound Statements - Sequences of Statements
1 [A statement is either simple or compound. A simple_statement encloses no
other statement. A compound_statement can enclose simple_statements and other
compound_statements.]
Syntax
2/3 {AI05-0179-1} sequence_of_statements ::= statement {statement
} {label}
3 statement ::=
{label} simple_statement | {label} compound_statement
4/2 {AI95-00318-02} simple_statement ::= null_statement
| assignment_statement | exit_statement
| goto_statement | procedure_call_statement
| simple_return_statement | entry_call_statement
| requeue_statement | delay_statement
| abort_statement | raise_statement
| code_statement
5/2 {AI95-00318-02} compound_statement ::=
if_statement | case_statement
| loop_statement | block_statement
| extended_return_statement
| accept_statement | select_statement
6 null_statement ::= null;
7 label ::= <<label_statement_identifier>>
8 statement_identifier ::= direct_name
9 The direct_name of a statement_identifier shall be an identifier (not
an operator_symbol).
Name Resolution Rules
10 The direct_name of a statement_identifier shall resolve to denote its
corresponding implicit declaration (see below).
Legality Rules
11 Distinct identifiers shall be used for all statement_identifiers that
appear in the same body, including inner block_statements but excluding inner
program units.
Static Semantics
12 For each statement_identifier, there is an implicit declaration (with the
specified identifier) at the end of the declarative_part of the innermost
block_statement or body that encloses the statement_identifier. The implicit
declarations occur in the same order as the statement_identifiers occur in the
source text. If a usage name denotes such an implicit declaration, the entity
it denotes is the label, loop_statement, or block_statement with the given
statement_identifier.
12.a Reason: We talk in terms of individual statement_identifiers here
rather than in terms of the corresponding statements, since a
given statement may have multiple statement_identifiers.
12.b A block_statement that has no explicit declarative_part has an
implicit empty declarative_part, so this rule can safely refer to
the declarative_part of a block_statement.
12.c The scope of a declaration starts at the place of the declaration
itself (see 8.2). In the case of a label, loop, or block name, it
follows from this rule that the scope of the implicit declaration
starts before the first explicit occurrence of the corresponding
name, since this occurrence is either in a statement label, a
loop_statement, a block_statement, or a goto_statement. An
implicit declaration in a block_statement may hide a declaration
given in an outer program unit or block_statement (according to
the usual rules of hiding explained in 8.3).
12.d The syntax rule for label uses statement_identifier which is a
direct_name (not a defining_identifier), because labels are
implicitly declared. The same applies to loop and block names. In
other words, the label itself is not the defining occurrence; the
implicit declaration is.
12.e We cannot consider the label to be a defining occurrence. An
example that can tell the difference is this:
12.f declare
-- Label Foo is implicitly declared here.
begin
for Foo in ... loop
...
<<Foo>> -- Illegal.
...
end loop;
end;
12.g/3 {AI05-0299-1} The label in this example is hidden from itself by
the loop parameter with the same name; the example is illegal. We
considered creating a new syntactic category name, separate from
direct_name and selector_name, for use in the case of statement
labels. However, that would confuse the rules in Clause 8, so we
didn't do it.
12.1/3 {AI05-0179-1} If one or more labels end a sequence_of_statements, an
implicit null_statement follows the labels before any following constructs.
12.g.1/3 Reason: The semantics of a goto_statement is defined in terms of
the statement having (following) that label. Thus we ensure that
every label has a following statement, which might be implicit.
Dynamic Semantics
13 The execution of a null_statement has no effect.
14/2 {AI95-00318-02} A transfer of control is the run-time action of an
exit_statement, return statement, goto_statement, or requeue_statement,
selection of a terminate_alternative, raising of an exception, or an abort,
which causes the next action performed to be one other than what would
normally be expected from the other rules of the language. [As explained in
7.6.1, a transfer of control can cause the execution of constructs to be
completed and then left, which may trigger finalization.]
15 The execution of a sequence_of_statements consists of the execution of the
individual statements in succession until the sequence_ is completed.
15.a Ramification: It could be completed by reaching the end of it, or
by a transfer of control.
NOTES
16 1 A statement_identifier that appears immediately within the
declarative region of a named loop_statement or an accept_statement is
nevertheless implicitly declared immediately within the declarative
region of the innermost enclosing body or block_statement; in other
words, the expanded name for a named statement is not affected by
whether the statement occurs inside or outside a named loop or an
accept_statement - only nesting within block_statements is relevant to
the form of its expanded name.
16.a Discussion: Each comment in the following example gives the
expanded name associated with an entity declared in the task body:
16.b task body Compute is
Sum : Integer := 0; -- Compute.Sum
begin
Outer: -- Compute.Outer
for I in 1..10 loop -- Compute.Outer.I
Blk: -- Compute.Blk
declare
Sum : Integer := 0; -- Compute.Blk.Sum
begin
accept Ent(I : out Integer; J : in Integer) do
-- Compute.Ent.I, Compute.Ent.J
Compute.Ent.I := Compute.Outer.I;
Inner: -- Compute.Blk.Inner
for J in 1..10 loop
-- Compute.Blk.Inner.J
Sum := Sum + Compute.Blk.Inner.J * Compute.Ent.J;
end loop Inner;
end Ent;
Compute.Sum := Compute.Sum + Compute.Blk.Sum;
end Blk;
end loop Outer;
Record_Result(Sum);
end Compute;
Examples
17 Examples of labeled statements:
18 <<Here>> <<Ici>> <<Aqui>> <<Hier>> null;
19 <<After>> X := 1;
Extensions to Ada 83
19.a The requeue_statement is new.
Wording Changes from Ada 83
19.b We define the syntactic category statement_identifier to simplify
the description. It is used for labels, loop names, and block
names. We define the entity associated with the implicit
declarations of statement names.
19.c Completion includes completion caused by a transfer of control,
although RM83-5.1(6) did not take this view.
Extensions to Ada 95
19.d/2 {AI95-00318-02} The extended_return_statement is new
(simple_return_statement is merely renamed).
Extensions to Ada 2005
19.e/3 {AI95-0179-1} A label can end a sequence_of_statements,
eliminating the requirement for having an explicit null; statement
after an ending label (a common use).
5.2 Assignment Statements
1 [An assignment_statement replaces the current value of a variable with the
result of evaluating an expression.]
Syntax
2 assignment_statement ::=
variable_name := expression;
3 The execution of an assignment_statement includes the evaluation of the
expression and the assignment of the value of the expression into the target.
[An assignment operation (as opposed to an assignment_statement) is performed
in other contexts as well, including object initialization and by-copy
parameter passing.] The target of an assignment operation is the view of the
object to which a value is being assigned; the target of an assignment_-
statement is the variable denoted by the variable_name.
3.a Discussion: Don't confuse this notion of the "target" of an
assignment with the notion of the "target object" of an entry call
or requeue.
3.b Don't confuse the term "assignment operation" with the
assignment_statement. The assignment operation is just one part of
the execution of an assignment_statement. The assignment operation
is also a part of the execution of various other constructs; see
7.6.1, "Completion and Finalization" for a complete list. Note
that when we say, "such-and-such is assigned to so-and-so", we
mean that the assignment operation is being applied, and that
so-and-so is the target of the assignment operation.
Name Resolution Rules
4/2 {AI95-00287-01} The variable_name of an assignment_statement is expected
to be of any type. The expected type for the expression is the type of the
target.
4.a Implementation Note: An assignment_statement as a whole is a
"complete context," so if the variable_name of an
assignment_statement is overloaded, the expression can be used to
help disambiguate it. For example:
4.b type P1 is access R1;
type P2 is access R2;
4.c function F return P1;
function F return P2;
4.d X : R1;
begin
F.all := X; -- Right hand side helps resolve left hand side
Legality Rules
5/2 {AI95-00287-01} The target [denoted by the variable_name] shall be a
variable of a nonlimited type.
6 If the target is of a tagged class-wide type T'Class, then the
expression shall either be dynamically tagged, or of type T and
tag-indeterminate (see 3.9.2).
6.a Reason: This is consistent with the general rule that a single
dispatching operation shall not have both dynamically tagged and
statically tagged operands. Note that for an object initialization
(as opposed to the assignment_statement), a statically tagged
initialization expression is permitted, since there is no chance
for confusion (or Tag_Check failure). Also, in an object
initialization, tag-indeterminate expressions of any type covered
by T'Class would be allowed, but with an assignment_statement,
that might not work if the tag of the target was for a type that
didn't have one of the dispatching operations in the
tag-indeterminate expression.
Dynamic Semantics
7 For the execution of an assignment_statement, the variable_name and the
expression are first evaluated in an arbitrary order.
7.a Ramification: Other rules of the language may require that the
bounds of the variable be determined prior to evaluating the
expression, but that does not necessarily require evaluation of
the variable_name, as pointed out by the ACID.
8 When the type of the target is class-wide:
9 * If the expression is tag-indeterminate (see 3.9.2), then the
controlling tag value for the expression is the tag of the target;
9.a Ramification: See 3.9.2, "
Dispatching Operations of Tagged Types".
10 * Otherwise [(the expression is dynamically tagged)], a check is made
that the tag of the value of the expression is the same as that of the
target; if this check fails, Constraint_Error is raised.
11 The value of the expression is converted to the subtype of the target.
[The conversion might raise an exception (see 4.6).]
11.a Ramification: 4.6, "Type Conversions" defines what actions and
checks are associated with subtype conversion. For non-array
subtypes, it is just a constraint check presuming the types match.
For array subtypes, it checks the lengths and slides if the target
is constrained. "Sliding" means the array doesn't have to have the
same bounds, so long as it is the same length.
12 In cases involving controlled types, the target is finalized, and an
anonymous object might be used as an intermediate in the assignment, as
described in 7.6.1, "Completion and Finalization". In any case, the converted
value of the expression is then assigned to the target, which consists of the
following two steps:
12.a To be honest: 7.6.1 actually says that finalization happens
always, but unless controlled types are involved, this
finalization during an assignment_statement does nothing.
13 * The value of the target becomes the converted value.
14/3 * {AI05-0299-1} If any part of the target is controlled, its value is
adjusted as explained in subclause 7.6.
14.a Ramification: If any parts of the object are controlled, abort is
deferred during the assignment operation itself, but not during
the rest of the execution of an assignment_statement.
NOTES
15 2 The tag of an object never changes; in particular, an
assignment_statement does not change the tag of the target.
16/2 This paragraph was deleted.{AI95-00363-01}
16.a Ramification: The implicit subtype conversion described above for
assignment_statements is performed only for the value of the
right-hand side expression as a whole; it is not performed for
subcomponents of the value.
16.b The determination of the type of the variable of an
assignment_statement may require consideration of the expression
if the variable name can be interpreted as the name of a variable
designated by the access value returned by a function call, and
similarly, as a component or slice of such a variable (see 8.6
, "The Context of Overload Resolution").
Examples
17 Examples of assignment statements:
18 Value := Max_Value - 1;
Shade := Blue;
19 Next_Frame(F)(M, N) := 2.5; -- see 4.1.1
U := Dot_Product(V, W); -- see 6.3
20/4 {AI12-0056-1}
Writer := (Status => Open, Unit => Printer, Line_Count => 60); -- see 3.8.1
Next.all := (72074, null, Head); -- see 3.10.1
21 Examples involving scalar subtype conversions:
22 I, J : Integer range 1 .. 10 := 5;
K : Integer range 1 .. 20 := 15;
...
23 I := J; -- identical ranges
K := J; -- compatible ranges
J := K; -- will raise Constraint_Error if K > 10
24 Examples involving array subtype conversions:
25 A : String(1 .. 31);
B : String(3 .. 33);
...
26 A := B; -- same number of components
27 A(1 .. 9) := "tar sauce";
A(4 .. 12) := A(1 .. 9); -- A(1 .. 12) = "tartar sauce"
NOTES
28 3 Notes on the examples: Assignment_statements are allowed even in
the case of overlapping slices of the same array, because the
variable_name and expression are both evaluated before copying the value into
the variable. In the above example, an implementation yielding A(1 ..
12) = "tartartartar" would be incorrect.
Extensions to Ada 83
28.a We now allow user-defined finalization and value adjustment
actions as part of assignment_statements (see 7.6, "
Assignment and Finalization").
Wording Changes from Ada 83
28.b The special case of array assignment is subsumed by the concept of
a subtype conversion, which is applied for all kinds of types, not
just arrays. For arrays it provides "sliding". For numeric types
it provides conversion of a value of a universal type to the
specific type of the target. For other types, it generally has no
run-time effect, other than a constraint check.
28.c We now cover in a general way in 3.7.2 the erroneous execution
possible due to changing the value of a discriminant when the
variable in an assignment_statement is a subcomponent that depends
on discriminants.
Incompatibilities With Ada 95
28.d/2 {AI95-00287-01} The change of the limited check from a resolution
rule to a legality rule is not quite upward compatible. For
example
28.e/2 type AccNonLim is access NonLim;
function Foo (Arg : in Integer) return AccNonLim;
type AccLim is access Lim;
function Foo (Arg : in Integer) return AccLim;
Foo(2).all := Foo(1).all;
28.f/2 where NonLim is a nonlimited type and Lim is a limited type. The
assignment is legal in Ada 95 (only the first Foo would be
considered), and is ambiguous in Ada 2005. We made the change
because we want limited types to be as similar to nonlimited types
as possible. Limited expressions are now allowed in all other
contexts (with a similar incompatibility), and it would be odd if
assignments had different resolution rules (which would eliminate
ambiguities in some cases). Moreover, examples like this one are
rare, as they depend on assigning into overloaded function calls.
5.3 If Statements
1 [An if_statement selects for execution at most one of the enclosed
sequences_of_statements, depending on the (truth) value of one or more
corresponding conditions.]
Syntax
2 if_statement ::=
if condition then
sequence_of_statements
{elsif condition then
sequence_of_statements}
[else
sequence_of_statements]
end if;
Paragraphs 3 and 4 were deleted.
Dynamic Semantics
5/3 {AI05-0264-1} For the execution of an if_statement, the condition
specified after if, and any conditions specified after elsif, are evaluated in
succession (treating a final else as elsif True then), until one evaluates to
True or all conditions are evaluated and yield False. If a condition evaluates
to True, then the corresponding sequence_of_statements is executed; otherwise,
none of them is executed.
5.a Ramification: The part about all evaluating to False can't happen
if there is an else, since that is herein considered equivalent to
elsif True then.
Examples
6 Examples of if statements:
7 if Month = December and Day = 31 then
Month := January;
Day := 1;
Year := Year + 1;
end if;
8 if Line_Too_Short then
raise Layout_Error;
elsif Line_Full then
New_Line;
Put(Item);
else
Put(Item);
end if;
9 if My_Car.Owner.Vehicle /= My_Car then -- see 3.10.1
Report ("Incorrect data");
end if;
Wording Changes from Ada 2005
9.a/3 {AI05-0147-1} Moved definition of condition to 4.5.7 in order to
eliminate a forward reference.
5.4 Case Statements
1 [A case_statement selects for execution one of a number of alternative
sequences_of_statements; the chosen alternative is defined by the value of an
expression.]
Syntax
2/3 {AI05-0188-1} case_statement ::=
case selecting_expression is
case_statement_alternative
{case_statement_alternative}
end case;
3 case_statement_alternative ::=
when discrete_choice_list =>
sequence_of_statements
Name Resolution Rules
4/3 {AI05-0188-1} The selecting_expression is expected to be of any discrete
type. The expected type for each discrete_choice is the type of the
selecting_expression.
Legality Rules
5/3 {AI05-0153-3} The choice_expressions, subtype_indications, and ranges
given as discrete_choices of a case_statement shall be static. [A
discrete_choice others, if present, shall appear alone and in the last
discrete_choice_list.]
6/3 {AI05-0188-1} {AI05-0240-1} The possible values of the
selecting_expression shall be covered (see 3.8.1) as follows:
6.a/3 Discussion: {AI05-0240-1} The meaning of "covered" here and in the
following rules is that of the term "cover a value" that is
defined in 3.8.1.
7/4 * {AI05-0003-1} {AI05-0153-3} {AI05-0188-1} {AI05-0262-1} {AI12-0071-1}
If the selecting_expression is a name [(including a type_conversion,
qualified_expression, or function_call)] having a static and
constrained nominal subtype, then each non-others discrete_choice
shall cover only values in that subtype that satisfy its predicates
(see 3.2.4), and each value of that subtype that satisfies its
predicates shall be covered by some discrete_choice [(either
explicitly or by others)].
7.a Ramification: Although not official names of objects, a value
conversion still has a defined nominal subtype, namely its target
subtype. See 4.6.
8/3 * {AI05-0188-1} If the type of the selecting_expression is root_integer,
universal_integer, or a descendant of a formal scalar type, then the
case_statement shall have an others discrete_choice.
8.a Reason: This is because the base range is implementation defined
for root_integer and universal_integer, and not known statically
in the case of a formal scalar type.
9/3 * {AI05-0188-1} Otherwise, each value of the base range of the type of
the selecting_expression shall be covered [(either explicitly or by
others)].
10 Two distinct discrete_choices of a case_statement shall not cover the same
value.
10.a/3 Ramification: {AI05-0188-1} The goal of these coverage rules is
that any possible value of the selecting_expression of a
case_statement should be covered by exactly one discrete_choice of
the case_statement, and that this should be checked at compile
time. The goal is achieved in most cases, but there are two minor
loopholes:
10.b * If the expression reads an object with an invalid
representation (e.g. an uninitialized object), then the value
can be outside the covered range. This can happen for static
constrained subtypes, as well as nonstatic or unconstrained
subtypes. It cannot, however, happen if the case_statement has
the discrete_choice others, because others covers all values,
even those outside the subtype.
10.c/3 * {AI95-00114-01} {AI05-0188-1} If the compiler chooses to
represent the value of an expression of an unconstrained
subtype in a way that includes values outside the bounds of
the subtype, then those values can be outside the covered
range. For example, if X: Integer := Integer'Last;, and the
case selecting_expression is X+1, then the implementation
might choose to produce the correct value, which is outside
the bounds of Integer. (It might raise Constraint_Error
instead.) This case can only happen for nongeneric subtypes
that are either unconstrained or nonstatic (or both). It can
only happen if there is no others discrete_choice.
10.d In the uninitialized variable case, the value might be anything;
hence, any alternative can be chosen, or Constraint_Error can be
raised. (We intend to prevent, however, jumping to random memory
locations and the like.) In the out-of-range case, the behavior is
more sensible: if there is an others, then the implementation may
choose to raise Constraint_Error on the evaluation of the
expression (as usual), or it may choose to correctly evaluate the
expression and therefore choose the others alternative. Otherwise
(no others), Constraint_Error is raised either way - on the
expression evaluation, or for the case_statement itself.
10.e For an enumeration type with a discontiguous set of internal codes
(see 13.4), the only way to get values in between the proper
values is via an object with an invalid representation; there is
no "out-of-range" situation that can produce them.
Dynamic Semantics
11/3 {AI05-0188-1} For the execution of a case_statement the
selecting_expression is first evaluated.
12/3 {AI05-0188-1} If the value of the selecting_expression is covered by the
discrete_choice_list of some case_statement_alternative, then the sequence_of_-
statements of the _alternative is executed.
13 Otherwise (the value is not covered by any discrete_choice_list, perhaps
due to being outside the base range), Constraint_Error is raised.
13.a Ramification: In this case, the value is outside the base range of
its type, or is an invalid representation.
NOTES
14 4 The execution of a case_statement chooses one and only one
alternative. Qualification of the expression of a case_statement by a
static subtype can often be used to limit the number of choices that
need be given explicitly.
Examples
15 Examples of case statements:
16 case Sensor is
when Elevation => Record_Elevation(Sensor_Value);
when Azimuth => Record_Azimuth (Sensor_Value);
when Distance => Record_Distance (Sensor_Value);
when others => null;
end case;
17 case Today is
when Mon => Compute_Initial_Balance;
when Fri => Compute_Closing_Balance;
when Tue .. Thu => Generate_Report(Today);
when Sat .. Sun => null;
end case;
18 case Bin_Number(Count) is
when 1 => Update_Bin(1);
when 2 => Update_Bin(2);
when 3 | 4 =>
Empty_Bin(1);
Empty_Bin(2);
when others => raise Error;
end case;
Incompatibilities With Ada 83
18.a.1/1 In Ada 95, function_calls and type_conversions are names, whereas
in Ada 83, they were expressions. Therefore, if the expression of
a case_statement is a function_call or type_conversion, and the
result subtype is static, it is illegal to specify a choice
outside the bounds of the subtype. For this case in Ada 83 choices
only are required to be in the base range of the type.
18.a.2/1 In addition, the rule about which choices must be covered is
unchanged in Ada 95. Therefore, for a case_statement whose
expression is a function_call or type_conversion, Ada 83 required
covering all choices in the base range, while Ada 95 only requires
covering choices in the bounds of the subtype. If the
case_statement does not include an others discrete_choice, then a
legal Ada 83 case_statement will be illegal in Ada 95 if the
bounds of the subtype are different than the bounds of the base
type.
Extensions to Ada 83
18.a In Ada 83, the expression in a case_statement is not allowed to be
of a generic formal type. This restriction is removed in Ada 95;
an others discrete_choice is required instead.
18.b In Ada 95, a function call is the name of an object; this was not
true in Ada 83 (see 4.1, "Names"). This change makes the following
case_statement legal:
18.c subtype S is Integer range 1..2;
function F return S;
case F is
when 1 => ...;
when 2 => ...;
-- No others needed.
end case;
18.d/3 {AI05-0005-1} Note that the result subtype given in a function
renaming_declaration is ignored; for a case_statement whose
expression calls a such a function, the full coverage rules are
checked using the result subtype of the original function. Note
that predefined operators such as "+" have an unconstrained result
subtype (see 4.5.1). Note that generic formal functions do not
have static result subtypes. Note that the result subtype of an
inherited subprogram need not correspond to any nameable subtype;
there is still a perfectly good result subtype, though.
Wording Changes from Ada 83
18.e Ada 83 forgot to say what happens for "legally" out-of-bounds
values.
18.f We take advantage of rules and terms (e.g. cover a value) defined
for discrete_choices and discrete_choice_lists in 3.8.1, "
Variant Parts and Discrete Choices".
18.g In the Name Resolution Rule for the case expression, we no longer
need RM83-5.4(3)'s "which must be determinable independently of
the context in which the expression occurs, but using the fact
that the expression must be of a discrete type," because the
expression is now a complete context. See 8.6, "
The Context of Overload Resolution".
18.h Since type_conversions are now defined as names, their coverage
rule is now covered under the general rule for names, rather than
being separated out along with qualified_expressions.
Wording Changes from Ada 2005
18.i/3 {AI05-0003-1} Rewording to reflect that a qualified_expression is
now a name.
18.j/3 {AI05-0153-3} Revised for changes to discrete_choices made to
allow static predicates (see 3.2.4) as case choices (see 3.8.1).
18.k/3 {AI05-0188-1} Added the selecting_ prefix to make this wording
consistent with case_expression, and to clarify which expression
is being talked about in the wording.
Wording Changes from Ada 2012
18.l/4 {AI12-0071-1} Corrigendum: Updated wording of case coverage to use
the new term "satisfies the predicates" (see 3.2.4).
5.5 Loop Statements
1 [A loop_statement includes a sequence_of_statements that is to be executed
repeatedly, zero or more times.]
Syntax
2 loop_statement ::=
[loop_statement_identifier:]
[iteration_scheme] loop
sequence_of_statements
end loop [loop_identifier];
3/3 {AI05-0139-2} iteration_scheme ::= while condition
| for loop_parameter_specification
| for iterator_specification
4 loop_parameter_specification ::=
defining_identifier in [reverse] discrete_subtype_definition
5 If a loop_statement has a loop_statement_identifier, then the
identifier shall be repeated after the end loop; otherwise, there
shall not be an identifier after the end loop.
Static Semantics
6 A loop_parameter_specification declares a loop parameter, which is an
object whose subtype is that defined by the discrete_subtype_definition.
Dynamic Semantics
7 For the execution of a loop_statement, the sequence_of_statements is
executed repeatedly, zero or more times, until the loop_statement is complete.
The loop_statement is complete when a transfer of control occurs that
transfers control out of the loop, or, in the case of an iteration_scheme, as
specified below.
8 For the execution of a loop_statement with a while iteration_scheme, the
condition is evaluated before each execution of the sequence_of_statements; if
the value of the condition is True, the sequence_of_statements is executed; if
False, the execution of the loop_statement is complete.
9/4 {AI05-0139-2} {AI05-0262-1} {AI12-0071-1} For the execution of a
loop_statement with the iteration_scheme being for
loop_parameter_specification, the loop_parameter_specification is first
elaborated. This elaboration creates the loop parameter and elaborates the
discrete_subtype_definition. If the discrete_subtype_definition defines a
subtype with a null range, the execution of the loop_statement is complete.
Otherwise, the sequence_of_statements is executed once for each value of the
discrete subtype defined by the discrete_subtype_definition that satisfies the
predicates of the subtype (or until the loop is left as a consequence of a
transfer of control). Prior to each such iteration, the corresponding value of
the discrete subtype is assigned to the loop parameter. These values are
assigned in increasing order unless the reserved word reverse is present, in
which case the values are assigned in decreasing order.
9.a Ramification: The order of creating the loop parameter and
evaluating the discrete_subtype_definition doesn't matter, since
the creation of the loop parameter has no side effects (other than
possibly raising Storage_Error, but anything can do that).
9.b/3 {AI05-0262-1} The predicate (if any) necessarily has to be a
static predicate as a dynamic predicate is explicitly disallowed -
see 3.2.4.
9.c/3 Reason: {AI05-0262-1} If there is a predicate, the loop still
visits the values in the order of the underlying base type; the
order of the values in the predicate is irrelevant. This is the
case so that the following loops have the same sequence of calls
and parameters on procedure Call for any subtype S:
9.d for I in S loop
Call (I);
end loop;
9.e for I in S'Base loop
if I in S then
Call (I);
end if;
end loop;
9.1/3 {AI05-0262-1} [For details about the execution of a loop_statement with
the iteration_scheme being for iterator_specification, see 5.5.2.]
NOTES
10 5 A loop parameter is a constant; it cannot be updated within the
sequence_of_statements of the loop (see 3.3).
11 6 An object_declaration should not be given for a loop parameter,
since the loop parameter is automatically declared by the
loop_parameter_specification. The scope of a loop parameter extends
from the loop_parameter_specification to the end of the
loop_statement, and the visibility rules are such that a loop
parameter is only visible within the sequence_of_statements of the
loop.
11.a Implementation Note: An implementation could give a warning if a
variable is hidden by a loop_parameter_specification.
12 7 The discrete_subtype_definition of a for loop is elaborated just
once. Use of the reserved word reverse does not alter the discrete
subtype defined, so that the following iteration_schemes are not
equivalent; the first has a null range.
13 for J in reverse 1 .. 0
for J in 0 .. 1
13.a Ramification: If a loop_parameter_specification has a static
discrete range, the subtype of the loop parameter is static.
Examples
14 Example of a loop statement without an iteration scheme:
15 loop
Get(Current_Character);
exit when Current_Character = '*';
end loop;
16 Example of a loop statement with a while iteration scheme:
17 while Bid(N).Price < Cut_Off.Price loop
Record_Bid(Bid(N).Price);
N := N + 1;
end loop;
18 Example of a loop statement with a for iteration scheme:
19 for J in Buffer'Range loop -- works even with a null range
if Buffer(J) /= Space then
Put(Buffer(J));
end if;
end loop;
20 Example of a loop statement with a name:
21 Summation:
while Next /= Head loop -- see 3.10.1
Sum := Sum + Next.Value;
Next := Next.Succ;
end loop Summation;
Wording Changes from Ada 83
21.a The constant-ness of loop parameters is specified in 3.3, "
Objects and Named Numbers".
Wording Changes from Ada 2005
21.b/3 {AI05-0139-2} {AI05-0262-1} {AI05-0299-1} Generalized
iterator_specifications are allowed in for loops; these are
documented as an extension in the appropriate subclause.
Wording Changes from Ada 2012
21.c/4 {AI12-0071-1} Corrigendum: Updated wording of loop execution to
use the new term "satisfies the predicates" (see 3.2.4).
5.5.1 User-Defined Iterator Types
Static Semantics
1/3 {AI05-0139-2} The following language-defined generic library package
exists:
2/3 generic
type Cursor;
with function Has_Element (Position : Cursor) return Boolean;
package Ada.Iterator_Interfaces is
pragma Pure (Iterator_Interfaces);
3/3 type Forward_Iterator is limited interface;
function First
(Object : Forward_Iterator) return Cursor is abstract;
function Next (Object : Forward_Iterator; Position : Cursor)
return Cursor is abstract;
4/3 type Reversible_Iterator is limited interface and Forward_Iterator;
function Last
(Object : Reversible_Iterator) return Cursor is abstract;
function Previous (Object : Reversible_Iterator; Position : Cursor)
return Cursor is abstract;
5/3 end Ada.Iterator_Interfaces;
6/3 {AI05-0139-2} An iterator type is a type descended from the
Forward_Iterator interface from some instance of Ada.Iterator_Interfaces. A
reversible iterator type is a type descended from the Reversible_Iterator
interface from some instance of Ada.Iterator_Interfaces. An iterator object is
an object of an iterator type. A reversible iterator object is an object of a
reversible iterator type. The formal subtype Cursor from the associated
instance of Ada.Iterator_Interfaces is the iteration cursor subtype for the
iterator type.
7/3 {AI05-0139-2} {AI05-0292-1} The following type-related operational aspects
may be specified for an indexable container type T (see 4.1.6):
8/3 Default_Iterator
This aspect is specified by a name that denotes exactly one
function declared immediately within the same declaration list
in which T is declared, whose first parameter is of type T or
T'Class or an access parameter whose designated type is type T
or T'Class, whose other parameters, if any, have default
expressions, and whose result type is an iterator type. This
function is the default iterator function for T. Its result
subtype is the default iterator subtype for T. The iteration
cursor subtype for the default iterator subtype is the default
cursor subtype for T.
8.a/3 Aspect Description for Default_Iterator: Default iterator to be
used in for loops.
9/3 Iterator_Element
This aspect is specified by a name that denotes a subtype.
This is the default element subtype for T.
9.a/3 Aspect Description for Iterator_Element: Element type to be used
for user-defined iterators.
10/3 These aspects are inherited by descendants of type T (including T'Class).
11/3 {AI05-0139-2} {AI05-0292-1} An iterable container type is an indexable
container type with specified Default_Iterator and Iterator_Element aspects. A
reversible iterable container type is an iterable container type with the
default iterator type being a reversible iterator type. An iterable container
object is an object of an iterable container type. A reversible iterable
container object is an object of a reversible iterable container type.
11.a.1/3 Glossary entry: An iterable container type is one that has
user-defined behavior for iteration, via the Default_Iterator and
Iterator_Element aspects.
11.1/4 {AI12-0138-1} The Default_Iterator and Iterator_Element aspects are
nonoverridable (see 13.1.1).
11.a/4 Reason: This ensures that all descendants of an iterable container
type have aspects with the same properties. This prevents generic
contract problems with formal derived types.
Legality Rules
12/3 {AI05-0139-2} {AI05-0292-1} The Constant_Indexing aspect (if any) of an
iterable container type T shall denote exactly one function with the following
properties:
13/3 * the result type of the function is covered by the default element
type of T or is a reference type (see 4.1.5) with an access
discriminant designating a type covered by the default element type of
T;
14/3 * the type of the second parameter of the function covers the default
cursor type for T;
15/3 * if there are more than two parameters, the additional parameters all
have default expressions.
16/3 This function (if any) is the default constant indexing function for T.
16.a/3 Ramification: This does not mean that Constant_Indexing has to
designate only one subprogram, only that there is only one routine
that meets all of these properties. There can be other routines
designated by Constant_Indexing, but they cannot have the profile
described above. For instance, map containers have a version of
Constant_Indexing that takes a key instead of a cursor; this is
allowed.
17/3 {AI05-0139-2} {AI05-0292-1} The Variable_Indexing aspect (if any) of an
iterable container type T shall denote exactly one function with the following
properties:
18/3 * the result type of the function is a reference type (see 4.1.5) with
an access discriminant designating a type covered by the default
element type of T;
19/3 * the type of the second parameter of the function covers the default
cursor type for T;
20/3 * if there are more than two parameters, the additional parameters all
have default expressions.
21/3 This function (if any) is the default variable indexing function for T.
Extensions to Ada 2005
21.a/3 {AI05-0139-2} User-defined iterator types are new in Ada 2012.
Incompatibilities With Ada 2012
21.b/4 {AI12-0138-1} Corrigendum: Defined Default_Iterator and
Iterator_Element to be nonoveridable, which makes redefinitions
and hiding of these aspects illegal. It's possible that some
program could violate one of these new restrictions, but in most
cases this can easily be worked around by using overriding rather
than redefinition.
5.5.2 Generalized Loop Iteration
1/3 {AI05-0139-2} Generalized forms of loop iteration are provided by an
iterator_specification.
Syntax
2/3 {AI05-0139-2} {AI05-0292-1} iterator_specification ::=
defining_identifier in [reverse] iterator_name
| defining_identifier [: subtype_indication
] of [reverse] iterable_name
Name Resolution Rules
3/3 {AI05-0139-2} {AI05-0292-1} For the first form of iterator_specification,
called a generalized iterator, the expected type for the iterator_name is any
iterator type. For the second form of iterator_specification, the expected
type for the iterable_name is any array or iterable container type. If the
iterable_name denotes an array object, the iterator_specification is called an
array component iterator; otherwise it is called a container element iterator.
3.a.1/3 Glossary entry: An iterator is a construct that is used to loop
over the elements of an array or container. Iterators may be user
defined, and may perform arbitrary computations to access elements
from a container.
Legality Rules
4/3 {AI05-0139-2} If the reserved word reverse appears, the
iterator_specification is a reverse iterator; otherwise it is a forward
iterator. In a reverse generalized iterator, the iterator_name shall be of a
reversible iterator type. In a reverse container element iterator, the default
iterator type for the type of the iterable_name shall be a reversible iterator
type.
5/4 {AI05-0139-2} {AI12-0151-1} The subtype defined by the
subtype_indication, if any, of an array component iterator shall statically
match the component subtype of the type of the iterable_name. The subtype
defined by the subtype_indication, if any, of a container element iterator
shall statically match the default element subtype for the type of the
iterable_name.
6/3 {AI05-0139-2} In a container element iterator whose iterable_name has type
T, if the iterable_name denotes a constant or the Variable_Indexing aspect is
not specified for T, then the Constant_Indexing aspect shall be specified for
T.
6.1/4 {AI12-0047-1} The iterator_name or iterable_name of an
iterator_specification shall not denote a subcomponent that depends on
discriminants of an object whose nominal subtype is unconstrained, unless the
object is known to be constrained.
6.a/4 Reason: This is the same rule that applies to renames; it serves
the same purpose of preventing the object from disappearing while
the iterator is still using it.
6.2/4 {AI12-0120-1} A container element iterator is illegal if the call of the
default iterator function that creates the loop iterator (see below) is
illegal.
6.b/4 Ramification: This can happen if the parameter to the default
iterator function is in out and the iterable_name is a constant.
The wording applies to any reason that the call would be illegal,
as it's possible that one of the default parameters would be
illegal, or that some accessibility check would fail.
6.3/4 {AI12-0120-1} A generalized iterator is illegal if the iteration cursor
subtype of the iterator_name is a limited type at the point of the generalized
iterator. A container element iterator is illegal if the default cursor
subtype of the type of the iterable_name is a limited type at the point of the
container element iterator.
6.c/4 Reason: If the cursor type is limited, the assignment to the loop
parameter for a generalized iterator would be illegal. The same is
true for a container element iterator. We have to say "at the
point of the iterator" as the limitedness of a type can change due
to visibility.
Static Semantics
7/3 {AI05-0139-2} {AI05-0269-1} {AI05-0292-1} An iterator_specification
declares a loop parameter. In a generalized iterator, the nominal subtype of
the loop parameter is the iteration cursor subtype. In an array component
iterator or a container element iterator, if a subtype_indication is present,
it determines the nominal subtype of the loop parameter. In an array component
iterator, if a subtype_indication is not present, the nominal subtype of the
loop parameter is the component subtype of the type of the iterable_name. In a
container element iterator, if a subtype_indication is not present, the
nominal subtype of the loop parameter is the default element subtype for the
type of the iterable_name.
8/3 {AI05-0139-2} {AI05-0292-1} In a generalized iterator, the loop parameter
is a constant. In an array component iterator, the loop parameter is a
constant if the iterable_name denotes a constant; otherwise it denotes a
variable. In a container element iterator, the loop parameter is a constant if
the iterable_name denotes a constant, or if the Variable_Indexing aspect is
not specified for the type of the iterable_name; otherwise it is a variable.
8.a/4 Ramification: {AI12-0093-1} The loop parameter of a generalized
iterator has the same accessibility as the loop statement. This
means that the loop parameter object is finalized when the loop
statement is left. (It also may be finalized as part of assigning
a new value to the loop parameter.) For array component iterators
and container element iterators, the loop parameter directly
denotes an element of the array or container and has the
accessibility of the associated array or container.
Dynamic Semantics
9/3 {AI05-0139-2} For the execution of a loop_statement with an
iterator_specification, the iterator_specification is first elaborated. This
elaboration elaborates the subtype_indication, if any.
10/3 {AI05-0139-2} For a generalized iterator, the loop parameter is created,
the iterator_name is evaluated, and the denoted iterator object becomes the
loop iterator. In a forward generalized iterator, the operation First of the
iterator type is called on the loop iterator, to produce the initial value for
the loop parameter. If the result of calling Has_Element on the initial value
is False, then the execution of the loop_statement is complete. Otherwise, the
sequence_of_statements is executed and then the Next operation of the iterator
type is called with the loop iterator and the current value of the loop
parameter to produce the next value to be assigned to the loop parameter. This
repeats until the result of calling Has_Element on the loop parameter is
False, or the loop is left as a consequence of a transfer of control. For a
reverse generalized iterator, the operations Last and Previous are called
rather than First and Next.
10.a/4 Ramification: {AI12-0093-1} The loop parameter of a generalized
iterator is a variable of which the user only has a constant view.
It follows the normal rules for a variable of its nominal subtype.
In particular, if the nominal subtype is indefinite, the variable
is constrained by its initial value. Similarly, if the nominal
subtype is class-wide, the variable (like all variables) has the
tag of the initial value. Constraint_Error may be raised by a
subsequent iteration if Next or Previous return an object with a
different tag or constraint.
11/3 {AI05-0139-2} {AI05-0292-1} For an array component iterator, the
iterable_name is evaluated and the denoted array object becomes the array for the loop.
If the array for the loop is a null array, then the execution of the
loop_statement is complete. Otherwise, the sequence_of_statements is executed
with the loop parameter denoting each component of the array for the loop,
using a canonical order of components, which is last dimension varying fastest
(unless the array has convention Fortran, in which case it is first dimension
varying fastest). For a forward array component iterator, the iteration starts
with the component whose index values are each the first in their index range,
and continues in the canonical order. For a reverse array component iterator,
the iteration starts with the component whose index values are each the last
in their index range, and continues in the reverse of the canonical order. The
loop iteration proceeds until the sequence_of_statements has been executed for
each component of the array for the loop, or until the loop is left as a
consequence of a transfer of control.
12/3 {AI05-0139-2} {AI05-0292-1} For a container element iterator, the
iterable_name is evaluated and the denoted iterable container object becomes
the iterable container object for the loop. The default iterator function for
the type of the iterable container object for the loop is called on the
iterable container object and the result is the loop iterator. An object of
the default cursor subtype is created (the loop cursor).
13/3 {AI05-0139-2} {AI05-0292-1} For a forward container element iterator, the
operation First of the iterator type is called on the loop iterator, to
produce the initial value for the loop cursor. If the result of calling
Has_Element on the initial value is False, then the execution of the
loop_statement is complete. Otherwise, the sequence_of_statements is executed
with the loop parameter denoting an indexing (see 4.1.6) into the iterable
container object for the loop, with the only parameter to the indexing being
the current value of the loop cursor; then the Next operation of the iterator
type is called with the loop iterator and the loop cursor to produce the next
value to be assigned to the loop cursor. This repeats until the result of
calling Has_Element on the loop cursor is False, or until the loop is left as
a consequence of a transfer of control. For a reverse container element
iterator, the operations Last and Previous are called rather than First and
Next. If the loop parameter is a constant (see above), then the indexing uses
the default constant indexing function for the type of the iterable container
object for the loop; otherwise it uses the default variable indexing function.
14/4 {AI12-0120-1} Any exception propagated by the execution of a generalized
iterator or container element iterator is propagated by the immediately
enclosing loop statement.
14.a/4 Ramification: This text covers exceptions raised by called
functions that make up the execution of the iterator as well as
exceptions raised by the assignment to the loop parameter or
cursor.
Examples
15/3 {AI05-0269-1} -- Array component iterator example:
for Element of Board loop -- See 3.6.1.
Element := Element * 2.0; -- Double each element of Board, a two-dimensional array.
end loop;
16/3 {AI05-0268-1} For examples of use of generalized iterators, see A.18.32
and the corresponding container packages in A.18.2 and A.18.3.
Extensions to Ada 2005
16.a/3 {AI05-0139-2} Generalized forms of loop iteration are new.
Incompatibilities With Ada 2012
16.b/4 {AI12-0047-1} Corrigendum: Added a rule to ensure that the object
being iterated cannot be a component that could disappear before
the loop completes. This could be incompatible by making a loop
that was legal (and worked correctly, so long as the enclosing
object is not modified during the loop) from the original Ada 2012
illegal in corrected Ada 2012. Such loops should be pretty rare,
especially as these iterator forms are new to Ada 2012.
16.c/4 {AI12-0120-1} Corrigendum: Added rules to reject loops if the call
to the default iterator function for a container element iterator
is illegal, or if the cursor type of an iterator is limited. These
are formally incompatible with original Ada 2012, but as it's
unlikely that any Ada 2012 compiler ever allowed the illegal
usages in an expansion of a loop (it's much more likely that they
would have just caused an internal error in the compiler), this
should have no effect in practice.
16.d/4 {AI12-0151-1} Corrigendum: Added a requirement that the given
subtype statically match the subtype of the element or component
for a component element iterator or array component iterator.
Original Ada 2012 text allowed any type that covered the subtype
of the element or component, but that led to questions of what the
meaning was if they are different. In this case, the element is
essentially a renaming of the container element, and it doesn't
make sense for the constraints to be different. Ignoring
explicitly defined constraints in renames is a mistake that we
don't want to continue, thus we require static matching. This
means that some programs might be illegal, but those programs were
misleading at best, and potentially would raise unexpected
exceptions because the element values might have been invalid or
abnormal with respect to the declared constraint.
Wording Changes from Ada 2012
16.e/4 {AI12-0120-1} Corrigendum: Added wording to specify that a loop
propagates any exceptions propagated by the execution of an
iterator. Since that's what naturally would happen from a
macro-style expansion of the parts of an iterator, and no other
interpretation makes sense given the way the rest of Ada works, we
consider it so unlikely that any Ada 2012 implementation ever did
anything else that we don't document this as a possible
inconsistency.
5.6 Block Statements
1 [A block_statement encloses a handled_sequence_of_statements optionally
preceded by a declarative_part.]
Syntax
2 block_statement ::=
[block_statement_identifier:]
[declare
declarative_part]
begin
handled_sequence_of_statements
end [block_identifier];
3 If a block_statement has a block_statement_identifier, then the
identifier shall be repeated after the end; otherwise, there shall not
be an identifier after the end.
Static Semantics
4 A block_statement that has no explicit declarative_part has an implicit
empty declarative_part.
4.a Ramification: Thus, other rules can always refer to the
declarative_part of a block_statement.
Dynamic Semantics
5 The execution of a block_statement consists of the elaboration of its
declarative_part followed by the execution of its
handled_sequence_of_statements.
Examples
6 Example of a block statement with a local variable:
7 Swap:
declare
Temp : Integer;
begin
Temp := V; V := U; U := Temp;
end Swap;
7.a Ramification: If task objects are declared within a
block_statement whose execution is completed, the
block_statement is not left until all its dependent tasks are
terminated (see 7.6). This rule applies to completion caused by a
transfer of control.
7.b Within a block_statement, the block name can be used in expanded
names denoting local entities such as Swap.Temp in the above
example (see 4.1.3).
Wording Changes from Ada 83
7.c The syntax rule for block_statement now uses the syntactic
category handled_sequence_of_statements.
5.7 Exit Statements
1 [An exit_statement is used to complete the execution of an enclosing
loop_statement; the completion is conditional if the exit_statement includes a
condition.]
Syntax
2 exit_statement ::=
exit [loop_name] [when condition];
Name Resolution Rules
3 The loop_name, if any, in an exit_statement shall resolve to denote a
loop_statement.
Legality Rules
4 Each exit_statement applies to a loop_statement; this is the
loop_statement being exited. An exit_statement with a name is only allowed
within the loop_statement denoted by the name, and applies to that loop_-
statement. An exit_statement without a name is only allowed within a loop_-
statement, and applies to the innermost enclosing one. An exit_statement that
applies to a given loop_statement shall not appear within a body or accept_-
statement, if this construct is itself enclosed by the given loop_statement.
Dynamic Semantics
5 For the execution of an exit_statement, the condition, if present, is
first evaluated. If the value of the condition is True, or if there is no
condition, a transfer of control is done to complete the loop_statement. If
the value of the condition is False, no transfer of control takes place.
NOTES
6 8 Several nested loops can be exited by an exit_statement that names
the outer loop.
Examples
7 Examples of loops with exit statements:
8 for N in 1 .. Max_Num_Items loop
Get_New_Item(New_Item);
Merge_Item(New_Item, Storage_File);
exit when New_Item = Terminal_Item;
end loop;
9 Main_Cycle:
loop
-- initial statements
exit Main_Cycle when Found;
-- final statements
end loop Main_Cycle;
5.8 Goto Statements
1 [A goto_statement specifies an explicit transfer of control from this
statement to a target statement with a given label.]
Syntax
2 goto_statement ::= goto label_name;
Name Resolution Rules
3 The label_name shall resolve to denote a label; the statement with that
label is the target statement.
Legality Rules
4 The innermost sequence_of_statements that encloses the target statement
shall also enclose the goto_statement. Furthermore, if a goto_statement is
enclosed by an accept_statement or a body, then the target statement shall not
be outside this enclosing construct.
4.a Ramification: The goto_statement can be a statement of an inner
sequence_.
4.b It follows from the second rule that if the target statement is
enclosed by such a construct, then the goto_statement cannot be
outside.
Dynamic Semantics
5 The execution of a goto_statement transfers control to the target
statement, completing the execution of any compound_statement that encloses
the goto_statement but does not enclose the target.
NOTES
6 9 The above rules allow transfer of control to a statement of an
enclosing sequence_of_statements but not the reverse. Similarly, they
prohibit transfers of control such as between alternatives of a
case_statement, if_statement, or select_statement; between
exception_handlers; or from an exception_handler of a
handled_sequence_of_statements back to its sequence_of_statements.
Examples
7 Example of a loop containing a goto statement:
8 <<Sort>>
for I in 1 .. N-1 loop
if A(I) > A(I+1) then
Exchange(A(I), A(I+1));
goto Sort;
end if;
end loop;
Generated by dwww version 1.15 on Sun Jun 16 17:20:14 CEST 2024.