CVS difference for ais/ai-10318.txt
--- ais/ai-10318.txt 2005/01/28 02:10:53 1.12
+++ ais/ai-10318.txt 2005/06/16 23:47:48 1.13
@@ -1,11 +1,19 @@
-!standard 03.10.02(10) 04-12-04 AI95-00318-02/08
+!standard 03.10.02(10) 05-05-16 AI95-00318-02/09
!standard 03.10.02(13)
!standard 03.08(14)
+!standard 03.09(24)
+!standard 04.03.03(11)
+!standard 05(02)
+!standard 05.01(04)
+!standard 05.01(05)
+!standard 05.01(14)
!standard 06.01(13)
!standard 06.01(23)
!standard 06.01(24)
!standard 06.01(28)
!standard 06.03.01(16)
+!standard 06.04(11)
+!standard 06.05(01)
!standard 06.05(02)
!standard 06.05(03)
!standard 06.05(04)
@@ -28,10 +36,16 @@
!standard 06.05(21)
!standard 06.05(22)
!standard 06.05(24)
+!standard 07.03(19)
!standard 07.05(02)
!standard 07.05(08)
!standard 07.05(09)
+!standard 07.06(17.1)
+!standard 07.06.01(02)
+!standard 07.06.01(18)
!standard 08.01(4)
+!standard 09.05.02(29)
+!standard 13.08(10)
!class amendment 02-10-09
!status Amendment 200Y 04-09-23
!status WG9 approved 04-11-18
@@ -166,8 +180,10 @@
Add before 3.8(14):
If a record_type_declaration includes the reserved word limited, the type
-is called a *limited record* type.
+is called an *explicitly limited record* type.
+In 3.9(24), change "return expression" to "return object".
+
Replace 3.10.2(10) with:
For any function, the accessibility level of the result object is that of the
@@ -179,6 +195,22 @@
type (see 6.5) is the same as that of the associated function or
access-to-subprogram type.
+Change 4.3.3(11) as follows:
+
+For an ..., the
+expression of a [return_statement]{return statement},
+the initialization expression in an object_declaration, or ...
+function [result]{return object}, object, or ...
+
+Replace "return_statement" with "return statement" in 5(2).
+
+Change "return_statement" in 5.1(4) to "simple_return_statement".
+
+Add "extended_return_statement" to 5.1(5).
+
+Replace "return_statement" with "return statement" in 5.1(14).
+
+
Change 6.1(13) to:
parameter_and_result_profile ::=
@@ -213,22 +245,23 @@
Modify 6.3.1(16) as follows:
+
+ Two profiles are mode conformant if they are type-conformant, and
+ corresponding parameters have identical modes, and, for access parameters
+ {or access result types}, the designated subtypes statically match.
- Two profiles are mode conformant if they are type-conformant, corresponding
- parameters have identical modes, and, for access parameters {or access result
- types}, the designated subtypes statically match.
+Replace "return_statement" with "return statement" in 6.4(11).
Replace clause 6.5 with the following:
6.5 Return Statements
- A return_statement is used to complete the execution of the innermost
+ 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
- return_statement ::= simple_return_statement | extended_return_statement
-
simple_return_statement ::= return [expression];
extended_return_statement ::=
@@ -242,21 +275,22 @@
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 expression, if any, of a
- simple_return_statement or extended_return_statement is called the *return
- expression*. The expected type for a return expression is the result type
+ 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.
Legality Rules
- A return_statement shall be within a callable construct, and it applies to
+ 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.
+ it. A return statement shall not be within a body that is within the
+ construct to which the return statement applies.
- A function body shall contain at least one return_statement that applies
+ 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 a return expression if and only if
+ 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.
@@ -268,7 +302,7 @@
subtype_indication shall also be constrained and shall statically match
this result subtype. If the result subtype of the function is
unconstrained, then the subtype defined by the subtype_indication shall be
- a definite subtype, or there shall be a return expression.
+ a definite subtype, or there shall be an expression.
If the result subtype of the function is defined by an access_definition,
the return_subtype_indication shall be an access_definition. The subtype
@@ -276,27 +310,27 @@
of the function. The accessibility level of this anonymous access subtype
is that of the result subtype.
- If the type of the return expression is limited, then the return expression
- shall be an aggregate, a function call (or equivalent use of an operator),
- or a qualified_expression or parenthesized expression whose operand is one
- of these.
+ If the result subtype of the function is limited, then the expression of the
+ return statement (if any) shall be an aggregate, a function call (or
+ equivalent use of an operator), or a qualified_expression or parenthesized
+ expression whose operand is one of these.
AARM Note:
- In other words, if limited, the return expression must produce a
+ In other words, if limited, the expression must produce a
"new" object, rather than being the name of a preexisting object
(which would imply copying).
Static Semantics
Within an extended_return_statement, the *return object* is declared with
- the given identifier, with nominal subtype defined by the
+ the given identifier, with the nominal subtype defined by the
return_subtype_indication.
Dynamic Semantics
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 a return expression, it is evaluated and
+ return object. If there is an expression, it is evaluated and
converted to the nominal subtype (which might raise Constraint_Error -- see 4.6)
and becomes the initial value of the return object; otherwise, the return
object is initialized by default as for a stand-alone object of its nominal
@@ -312,8 +346,8 @@
tag of the return object is that of the result type.
AARM Ramification:
- This is true even if the tag of the return expression is different, which
- could happen if the return expression were a view conversion or a
+ This 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.
@@ -327,7 +361,7 @@
Finally, a transfer of control is performed which completes the
- execution of the construct to which the return_statement applies,
+ execution of the construct to which the return statement applies,
and returns to the caller. In the case of a function, the
function_call denotes a constant view of the return object.
@@ -345,27 +379,48 @@
Node.Succ := Next_Node;
end return;
+Delete all but the first sentence of 7.3(19).
+
The new rule added before 7.5(2) by AI-287 should say:
...unless it is an aggregate, a function_call, or a parenthesized...
A new bullet should be added to the list here:
- * the expression of a return_statement (see 6.5)
+ * the expression of a return statement (see 6.5)
The following should be added to the new rule added after 7.5(8) by AI-287:
For a function_call of a type with a part that is of a task, protected, or
-limited record type that is used to initialize an object as allowed above, the
-implementation shall not create a separate return object (see 6.5) for the
-function_call. The function_call shall be constructed directly in the
+explictly limited record type that is used to initialize an object as allowed
+above, the implementation shall not create a separate return object (see 6.5)
+for the function_call. The function_call shall be constructed directly in the
new object.
Similarly, the replacement note of 7.5(9)
of AI-287 should say "aggregate or function_call" in each occurrence.
+Replace 7.6(17.1) with:
+
+For an aggregate of a controlled type whose value is assigned, other than by an
+assignment_statement or a simple_return_statement of a return type with no part
+that is of a task, protected, or explicitly limited record type, the
+implementation shall not create a separate anonymous object for the aggregate.
+The aggregate value shall be constructed directly in the target of the
+assignment operation and Adjust is not called on the target object.
+
+Replace part of 7.6.1(2) and 7.6.1(18) as follows:
+
+"...[exit_, return_, goto_]{exit_statement, return statement,
+goto_statement},..."
+
+[Editor's note: removing the "cute" wording here improves searchability of
+the Standard; we should avoid use abbreviations of technical terms.]
+
Add after 8.1(4):
* an extended_return_statement;
+Replace "return_statement" with "return statement" in 9.5.2(29).
+
!example
Here is an example of a function with a limited result type
@@ -673,8 +728,17 @@
in the @fa<component_definition>, then the component is aliased (see 3.10).
@dinst
If a @fa<record_type_declaration> includes the reserved word @b<limited>, the
-type is called a @i<limited record> type.
+type is called an @i<explicitly limited record> type.
+
+!corrigendum 3.9(24)
+@drepl
+@xbullet<The tag of the result returned by a function with a class-wide result
+type is that of the return expression.>
+@dby
+@xbullet<The tag of the result returned by a function with a class-wide result
+type is that of the return object.>
+
!corrigendum 3.10.2(10)
@drepl
@@ -698,6 +762,102 @@
result type (see 6.5) is the same as that of the associated function or
access-to-subprogram type.>
+!corrigendum 4.3.3(11)
+
+@drepl
+For an @fa<explicit_actual_parameter>, an
+@fa<explicit_generic_actual_parameter>, the
+@fa<expression> of a @fa<return_statement>, the initialization expression in an
+@fa<object_declaration>, or a @fa<default_expression> (for a parameter or a
+component), when the nominal subtype of the corresponding formal parameter,
+generic formal parameter, function result, object, or component is a
+constrained array subtype, the applicable index constraint is the constraint of
+the subtype;
+@dby
+For an @fa<explicit_actual_parameter>, an
+@fa<explicit_generic_actual_parameter>, the
+@fa<expression> of a return statement, the initialization expression in an
+@fa<object_declaration>, or a @fa<default_expression> (for a parameter or a
+component), when the nominal subtype of the corresponding formal parameter,
+generic formal parameter, function return object, object, or component is a
+constrained array subtype, the applicable index constraint is the constraint of
+the subtype;
+
+
+!corrigendum 5(2)
+
+@drepl
+This section describes the general rules applicable to all @fa<statement>s. Some
+@fa<statement>s are discussed in later sections: @fa<Procedure_call_statement>s and
+@fa<return_statement>s are described in 6, "Subprograms".
+@fa<Entry_call_statement>s, @fa<requeue_statement>s, @fa<delay_statement>s,
+@fa<accept_statement>s, @fa<select_statement>s, and @fa<abort_statement>s are
+described in 9, "Tasks and Synchronization". @fa<Raise_statement>s are
+described in 11, "Exceptions", and @fa<code_statement>s in 13. The remaining
+forms of @fa<statement>s are presented in this section.
+@dby
+This section describes the general rules applicable to all @fa<statement>s. Some
+@fa<statement>s are discussed in later sections: @fa<Procedure_call_statement>s and
+return statements are described in 6, "Subprograms".
+@fa<Entry_call_statement>s, @fa<requeue_statement>s, @fa<delay_statement>s,
+@fa<accept_statement>s, @fa<select_statement>s, and @fa<abort_statement>s are
+described in 9, "Tasks and Synchronization". @fa<Raise_statement>s are
+described in 11, "Exceptions", and @fa<code_statement>s in 13. The remaining
+forms of @fa<statement>s are presented in this section.
+
+
+!corrigendum 5.1(4)
+
+@drepl
+@xcode<@fa<simple_statement ::= null_statement
+ | assignment_statement | exit_statement
+ | goto_statement | procedure_call_statement
+ | return_statement | entry_call_statement
+ | requeue_statement | delay_statement
+ | abort_statement | raise_statement
+ | code_statement>>
+@dby
+@xcode<@fa<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>>
+
+!corrigendum 5.1(5)
+
+@drepl
+@xcode<@fa<compound_statement ::=
+ if_statement | case_statement
+ | loop_statement | block_statement
+ | accept_statement | select_statement>>
+@dby
+@xcode<@fa<compound_statement ::=
+ if_statement | case_statement
+ | loop_statement | block_statement
+ | extended_return_statement
+ | accept_statement | select_statement>>
+
+!corrigendum 5.1(14)
+
+@drepl
+A @i<transfer of control> is the run-time action of an @fa<exit_statement>,
+@fa<return_statement>, @fa<goto_statement>, or @fa<requeue_statement>,
+selection of a @fa<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.
+@dby
+A @i<transfer of control> is the run-time action of an @fa<exit_statement>,
+return statement, @fa<goto_statement>, or @fa<requeue_statement>,
+selection of a @fa<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.
+
!corrigendum 6.1(13)
@drepl
@@ -759,17 +919,37 @@
corresponding parameters have identical modes, and, for access parameters, the
designated subtypes statically match.
@dby
-Two profiles are @i<mode conformant> if they are type-conformant,
+Two profiles are @i<mode conformant> if they are type-conformant, and
corresponding parameters have identical modes, and, for access parameters or
access result types, the designated subtypes statically match.
+!corrigendum 6.4(11)
+
+@drepl
+The exception Program_Error is raised at the point of a @fa<function_call> if
+the function completes normally without executing a @fa<return_statement>.
+@dby
+The exception Program_Error is raised at the point of a @fa<function_call> if
+the function completes normally without executing a return statement.
+
+!corrigendum 6.5(1)
+
+@drepl
+A @fa<return_statement> is used to complete the execution of the
+innermost enclosing @fa<subprogram_body>, @fa<entry_body>, or
+@fa<accept_statement>.
+@dby
+A @fa<simple_return_statement> or @fa<extended_return_statement> (collectively
+called a @i<return statement>) is used to complete the execution of the
+innermost enclosing @fa<subprogram_body>, @fa<entry_body>, or
+@fa<accept_statement>.
+
+
!corrigendum 6.5(2)
@drepl
@xcode<@fa<return_statement ::= >@ft<@b<return>>@fa< [expression];>>
@dby
-@xcode<@fa<return_statement ::= simple_return_statement | extended_return_statement>>
-
@xcode<@fa<simple_return_statement ::= >@ft<@b<return>>@fa< [expression];>>
@xcode<@fa<extended_return_statement ::=
@@ -790,10 +970,11 @@
@dby
The @i<result subtype> of a function is the subtype denoted by the
@fa<subtype_mark>, or defined by the @fa<access_definition>, after the reserved
-word @b<return> in the profile of the function. The @fa<expression>, if any, of
-a @fa<simple_return_statement> or @fa<extended_return_statement> is called the
-@i<return expression>. The expected type for a return expression is the result
+word @b<return> in the profile of the function. The expected type for the
+@fa<expression>, if any, of a @fa<simple_return_statement> is the result
type of the corresponding function.
+The expected type for the @fa<expression> of an @fa<extended_return_statement>
+is that of the @fa<return_subtype_indication>.
!corrigendum 6.5(04)
@@ -802,10 +983,10 @@
to> the innermost one. A @fa<return_statement> shall not be within a body that
is within the construct to which the @fa<return_statement> applies.
@dby
-A @fa<return_statement> shall be within a callable construct, and it @i<applies
+A return statement shall be within a callable construct, and it @i<applies
to> the innermost callable construct or @fa<extended_return_statement> that
-contains it. A @fa<return_statement> shall not be within a body that is within
-the construct to which the @fa<return_statement> applies.
+contains it. A return statement shall not be within a body that is within
+the construct to which the return statement applies.
!corrigendum 6.5(05)
@@ -815,9 +996,9 @@
@fa<return_statement> shall include a return expression if and only if
it applies to a function body.
@dby
-A function body shall contain at least one @fa<return_statement> that applies
+A function body shall contain at least one return statement that applies
to the function body, unless the function contains @fa<code_statement>s. A
-@fa<simple_return_statement> shall include a return expression if and only if
+@fa<simple_return_statement> shall include an @fa<expression> if and only if
it applies to a function body. An @fa<extended_return_statement> shall apply to
a function body.
@@ -829,7 +1010,7 @@
@fa<subtype_indication> shall also be constrained and shall statically match
this result subtype. If the result subtype of the function is unconstrained,
then the subtype defined by the @fa<subtype_indication> shall be a definite
-subtype, or there shall be a return expression.
+subtype, or there shall be an @fa<expression>.
If the result subtype of the function is defined by an @fa<access_definition>,
the @fa<return_subtype_indication> shall be an @fa<access_definition>. The
@@ -837,15 +1018,15 @@
subtype of the function. The accessibility level of this anonymous access
subtype is that of the result subtype.
-If the type of the return expression is limited, then the return expression
-shall be an aggregate, a function call (or equivalent use of an operator),
-or a @fa<qualified_expression> or parenthesized expression whose operand is one
-of these.
+If the result subtype of the function is limited, then the @fa<expression>
+of the return statement (if any) shall be an @fa<aggregate>, a function call
+(or equivalent use of an operator), or a @fa<qualified_expression> or
+parenthesized expression whose operand is one of these.
@i<@s8<Static Semantics>>
Within an @fa<extended_return_statement>, the @i<return object> is declared
-with the given identifier, with nominal subtype defined by the
+with the given identifier, with the nominal subtype defined by the
@fa<return_subtype_indication>.
!corrigendum 6.5(06)
@@ -856,7 +1037,7 @@
@dby
For the execution of an @fa<extended_return_statement>, the
@fa<subtype_indication> or @fa<access_definition> is elaborated. This creates
-the nominal subtype of the return object. If there is a return expression,
+the nominal subtype of the return object. If there is an @fa<expression>,
it is evaluated and converted
to the nominal subtype (which might raise Constraint_Error -- see 4.6) and
becomes the initial value of the return object; otherwise, the return object is
@@ -965,30 +1146,48 @@
@drepl
Finally, a transfer of control is performed which completes the
-execution of the construct to which the @fa<return_statement> applies,
+execution of the callable construct to which the @fa<return_statement> applies,
and returns to the caller.
@dby
Finally, a transfer of control is performed which completes the
-execution of the construct to which the @fa<return_statement> applies,
+execution of the construct to which the return statement applies,
and returns to the caller. In the case of a function, the
@fa<function_call> denotes a constant view of the return object.
!corrigendum 6.5(24)
@drepl
-@xcode<@b<return>; -- @ft<@i<in a procedure body, >>@fa<entry_body>@ft<@i<, or >>@fa<accept_statement>
-@b<return> Key_Value(Last_Index); -- @ft<@i<in a function body>>>
+@xcode<@b<return>; --@ft<@i< in a procedure body, >>@fa<entry_body>@ft<@i<, or >>@fa<accept_statement>
+@b<return> Key_Value(Last_Index); --@ft<@i< in a function body>>>
@dby
-@xcode<@b<return>; -- @ft<@i<in a procedure body, >>@fa<entry_body>@ft<@i<,>>
+@xcode<@b<return>; --@ft<@i< in a procedure body, >>@fa<entry_body>@ft<@i<,>>
-- @fa<accept_statement>@ft<@i<, or >>@fa<extended_return_statement>>
-@xcode<@b<return> Key_Value(Last_Index); -- @ft<@i<in a function body>>>
+@xcode<@b<return> Key_Value(Last_Index); --@ft<@i< in a function body>>>
-@xcode<@b<return> Node : Cell @b<do> -- @ft<@i<in a function body, see 3.10.1 for Cell>>
+@xcode<@b<return> Node : Cell @b<do> --@ft<@i< in a function body, see 3.10.1 for Cell>>
Node.Value := Result;
Node.Succ := Next_Node;
@b<end return>;>
+!corrigendum 7.3(19)
+
+@drepl
+Declaring a private type with an @fa<unknown_discriminant_part> is a
+way of preventing clients from creating uninitialized objects of the
+type; they are then forced to initialize each object by calling some
+operation declared in the visible part of the package.
+If such a type is also limited, then no objects of the type can
+be declared outside the scope of the @fa<full_type_declaration>, restricting
+all object creation to the package defining the type. This allows
+complete control over all storage allocation for the type.
+Objects of such a type can still be passed as parameters, however.
+@dby
+Declaring a private type with an @fa<unknown_discriminant_part> is a
+way of preventing clients from creating uninitialized objects of the
+type; they are then forced to initialize each object by calling some
+operation declared in the visible part of the package.
+
!corrigendum 7.5(2)
!comment This rule only talks about function_calls, because those are only
!comment appropriate here. The conflict text handles the combination of
@@ -1009,7 +1208,7 @@
@xbullet<an @fa<expression> of a @fa<positional_array_aggregate> or the
@fa<expression> of an @fa<array_component_association> (see 4.3.3)>
@xbullet<the @fa<qualified_expression> of an initialized allocator (see 4.8)>
-@xbullet<the @fa<expression> of a @fa<return_statement> (see 6.5)>
+@xbullet<the @fa<expression> of a return statement (see 6.5)>
@xbullet<the @fa<default_expression> or actual parameter for a formal object
of mode @b<in> (see 12.4)>
@@ -1021,21 +1220,79 @@
@i<@s8<Implementation Requirements>>
For a @fa<function_call> of a type with a part that is of a task, protected, or
-limited record type that is used to initialize an object as allowed above, the
-implementation shall not create a separate return object (see 6.5) for the
-@fa<function_call>. The @fa<function_call> shall be constructed directly in the
-new object.
+explicitly limited record type that is used to initialize an object as allowed
+above, the implementation shall not create a separate return object (see 6.5)
+for the @fa<function_call>. The @fa<function_call> shall be constructed
+directly in the new object.
!corrigendum 7.5(9)
@drepl
-@xindent<@s9<13 The following are consequences of the rules for limited types: >>
+@xindent<@s9<13 The following are consequences of the rules for limited types: >>
@dby
-@xindent<@s9<13 While it is allowed to write initializations of limited objects,
+@xindent<@s9<13 While it is allowed to write initializations of limited objects,
such initializations never copy a limited object. The source of such an
assignment operation must be a @fa<function_call>, and such @fa<function_call>s
must be built directly in the target object.>>
+!corrigendum 7.6(17.1)
+
+@drepl
+For an @fa<aggregate> of a controlled type whose value is assigned,
+other than by an @fa<assignment_statement> or a
+@fa<return_statement>, the implementation shall not create a separate
+anonymous object for the @fa<aggregate>. The aggregate value shall be
+constructed directly in the target of the assignment operation and Adjust is
+not called on the target object.
+@dby
+For an @fa<aggregate> of a controlled type whose value is assigned,
+other than by an @fa<assignment_statement> or a
+@fa<simple_return_statement> of a return type with no part that is of a task,
+protected, or explicitly limited record type, the implementation shall not
+create a separate
+anonymous object for the @fa<aggregate>. The aggregate value shall be
+constructed directly in the target of the assignment operation and Adjust is
+not called on the target object.
+
+!corrigendum 7.6.1(2)
+
+@drepl
+The execution of a construct or entity is @i<complete> when the end of that
+execution has been reached, or when a transfer of control (see 5.1) causes it
+to be abandoned. Completion due to reaching the end of
+execution, or due to the transfer of control of an @fa<exit_>, @fa<return_>,
+@fa<goto_>, or @fa<requeue_statement> or of the selection of a
+@fa<terminate_alternative> is @i<normal completion>. Completion is
+@i<abnormal> otherwise @emdash when control is transferred out
+of a construct due to abort or the raising of an exception.
+@dby
+The execution of a construct or entity is @i<complete> when the end of that
+execution has been reached, or when a transfer of control (see 5.1) causes it
+to be abandoned. Completion due to reaching the end of
+execution, or due to the transfer of control of an @fa<exit_statement>,
+return statement, @fa<goto_statement>, or @fa<requeue_statement> or of the
+selection of a @fa<terminate_alternative> is @i<normal completion>. Completion
+is @i<abnormal> otherwise @emdash when control is transferred out of a construct due
+to abort or the raising of an exception.
+
+!corrigendum 7.6.1(18)
+
+@drepl
+For a Finalize invoked by the transfer of control of an @fa<exit_>,
+@fa<return_>, @fa<goto_>, or @fa<requeue_statement>, Program_Error is raised no
+earlier than after the finalization of the master being finalized when the
+exception occurred, and no later than the point where normal execution would
+have continued. Any other finalizations due to be performed up to that point
+are performed before raising Program_Error.
+@dby
+For a Finalize invoked by the transfer of control of an @fa<exit_statement>,
+return statement, @fa<goto_statement>, or @fa<requeue_statement>, Program_Error
+is raised no earlier than after the finalization of the master being finalized
+when the exception occurred, and no later than the point where normal execution
+would have continued. Any other finalizations due to be performed up to that
+point are performed before raising Program_Error.
+
+
!corrigendum 8.1(4)
@dinsa
@@ -1043,6 +1300,28 @@
@dinst
@xbullet<an @fa<extended_return_statement>;>
+!corrigendum 9.5.2(29)
+
+@drepl
+@xindent<@s9<24 A @fa<return_statement> (see 6.5) or a @fa<requeue_statement>
+(see 9.5.4) may be used to complete the execution of an @fa<accept_statement>
+or an @fa<entry_body>.>>
+@dby
+@xindent<@s9<24 A return statement (see 6.5) or a @fa<requeue_statement>
+(see 9.5.4) may be used to complete the execution of an @fa<accept_statement>
+or an @fa<entry_body>.>>
+
+!corrigendum 13.8(10)
+
+@drepl
+@xindent<@s9<16 Machine code functions are exempt from the rule that a
+@fa<return_statement> is required. In fact, @fa<return_statement>s are
+forbidden, since only @fa<code_statement>s are allowed.>>
+@dby
+@xindent<@s9<16 Machine code functions are exempt from the rule that a
+return statement is required. In fact, return statements are
+forbidden, since only @fa<code_statement>s are allowed.>>
+
!ACATS test
@@ -1590,4 +1869,132 @@
users another (but different) crippled version of limited types.
****************************************************************
+
+From: Bob Duff
+Sent: Monday, June 6, 2005 12:35 PM
+
+I'm using draft 11.8 of the [A]ARM.
+
+3.8(13.1/2):
+
+13.1/2 {AI95-00318-02} If a record_type_declaration includes the reserved word
+limited, the type is called a limited record type.
+
+So "limited record type" is not synonymous with "record type that is limited"?!
+That seems rather confusing. How about renaming this concept "explicitly
+limited record type"?
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Monday, June 6, 2005 7:08 PM
+
+Sounds reasonable. I can't imagine this special
+term is used very much, and it would be wise
+to be as "explicit" as possible... ;-)
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Monday, June 6, 2005 9:18 PM
+
+That seems OK to me, although finding where it is used is going to be
+tricky. (Which, I suppose, is the point.)
+
+****************************************************************
+
+From: Bob Duff
+Sent: Tuesday, June 7, 2005 6:46 AM
+
+3.7(10.f/2, 10.i/2)
+
+3.8(13.1/2, 31.i/2)
+
+7.5(8.1/2)
+
+7.6(17.1/2)
+
+10.2.1(28.e/2)
+
+D.10(5.a)
+
+I don't know which of the above are old wording that was intended to
+mean "record type that is limited".
+
+The term does not appear in the Index.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Saturday, June 11, 2005 12:35 AM
+
+Bob gives a list of places to change:
+
+> 3.7(10.f/2, 10.i/2)
+
+Interestingly, the notes use the new term, the normative wording here uses
+the old gobbledygook. Should 3.7(10) be changed to use "explicitly limited
+record type" like all of the new wording?? It would seem to be more
+consistent.
+
+> 3.8(13.1/2, 31.i/2)
+>
+> 7.5(8.1/2)
+>
+> 7.6(17.1/2)
+>
+> 10.2.1(28.e/2)
+
+These are all uses of the new term.
+
+> D.10(5.a)
+
+This is an old use of the new term; the meaning is exactly what we mean. So
+I guess there wasn't any confusion. :-)
+
+> I don't know which of the above are old wording that was intended to
+> mean "record type that is limited".
+
+None, amazingly. But you didn't look for "limited record", which might find
+more hits.
+
+> The term does not appear in the Index.
+
+It does now.
+
+****************************************************************
+
+From: Pascal Leroy
+Sent: Saturday, June 11, 2005 3:52 AM
+
+> > 3.7(10.f/2, 10.i/2)
+>
+> Interestingly, the notes use the new term, the normative
+> wording here uses the old gobbledygook. Should 3.7(10) be
+> changed to use "explicitly limited record type" like all of
+> the new wording?? It would seem to be more consistent.
+
+It should be changed to use the new terminology, but it must still talk
+about ancestors and all that, so the sentence will remain rather
+convoluted.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Monday, June 13, 2005 10:51 PM
+
+Turns out that we have to change it, because a "type containing the reserved
+word limited" clearly includes derived types that explicitly include limited,
+but we certainly don't want them to (it wouldn't necessarily be a "really
+limited" type).
+
+ type L (...) is limited private;
+
+ type D (...) is new limited L;
+
+D meets the letter of the old rule, but shouldn't be included if L is actually
+completed by Integer (say).
+
+****************************************************************
+
Questions? Ask the ACAA Technical Agent