CVS difference for ais/ai-00318.txt

Differences between 1.8 and version 1.9
Log of other versions for file ais/ai-00318.txt

--- ais/ai-00318.txt	2004/01/23 04:59:27	1.8
+++ ais/ai-00318.txt	2004/03/02 01:24:38	1.9
@@ -1,4 +1,4 @@
-!standard 03.03.01  (02)                              03-12-10  AI95-00318/02
+!standard 03.03.01  (02)                              04-02-28  AI95-00318/03
 !standard 06.05.00  (17)
 !standard 06.05.00  (18)
 !class amendment 02-10-09
@@ -100,7 +100,7 @@
 
 [Question: Should an expression-less return statement be permitted
 within the handled_sequence_of_statements?  That would be consistent
-with the way that accept statements work.]
+with the way that accept statements work. Tentative ARG Answer: Yes.]
 
 A call of a non-return-by-reference function with a limited result type may
 be used in the same contexts where we have proposed to allow aggregates of a
@@ -125,13 +125,13 @@
   9) Use of the function call as a prefix to 'Address
 
 In other words, it would be permitted in *any* context where limited types
-are permitted.  With the new proposals, that is pretty much *any* context
+are permitted. With the new proposals, that is pretty much *any* context
 where a "name" that denotes an object or value is permitted, except as the
 right hand side of an assignment statement.
 
 Note that a call of a return by reference function, because it is represents
 a view of a preexisting object, is not permitted in contexts 1, 2, 3, 4, and 6
-if the result type is limited.  Such a call *would* be permitted in the
+if the result type is limited. Such a call *would* be permitted in the
 expression  of a return statement for another return-by-reference function.
 
 
@@ -151,6 +151,164 @@
 
 !wording
 
+Change 6.1(13) to:
+
+    parameter_and_result_profile ::= [formal_part] [ALIASED] RETURN subtype_mark
+
+Modify 6.3.1(16) as follows:
+
+    Two profiles are mode conformant if they are type-conformant, {if for
+    functions, both or neither are return-by-reference (see 6.5),}
+    corresponding parameters have identical modes, and, for access parameters,
+    the designated subtypes statically match.
+
+Replace clause 6.5 with the following:
+
+6.5 Return Statements
+
+    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 ::=
+         RETURN identifier : [ALIASED] subtype_indication [:= expression] [DO
+           handled_sequence_of_statements
+         END RETURN];
+
+               Name Resolution Rules
+
+    The result subtype of a function is the subtype denoted by the
+    subtype_mark after the reserved word RETURN in the profile of the
+    function. If the reserved word ALIASED precedes RETURN, it is a
+    *return-by-reference* function. The expression, if any, of a
+    return_statement is called the return expression. The expected type for a
+    return expression is the result type of the corresponding function.
+
+                Legality Rules
+
+    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.
+
+    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
+    it applies to a function body. An extended_return_statement shall apply to
+    a function body, and the function shall not be return-by-reference.
+
+    For a return-by-reference function, the return expression of the
+    simple_return_statement shall be a name that denotes an aliased view of an
+    object. For a non return-by-reference function with limited result type,
+    the object associated with the return expression, if any, shall be an
+    object defined by an aggregate or a function_call on a non
+    return-by-reference function.
+
+    The type of the subtype_indication of an extended_return_statement shall
+    be the result type of the function. If the result subtype of the function
+    is constrained, then the subtype defined by the subtype_indication of the
+    extended_return_statement 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.
+
+    For a non return-by-reference function with limited result type, the
+    result subtype shall be constrained.
+
+    AARM NOTE: This last paragraph is not a necessary restriction, but
+    simplifies implementation dramatically, since it means the caller can
+    always allocate space for the result object, perform all "implicit"
+    initializations of task and protected components, worry about
+    accessibility levels for access discriminants, etc. The restriction could
+    be lifted in Ada 201Z.
+
+    AARM Ramification: Note that this rule is defined at the point of the
+    return statement rather than at the point of the function declaration, to
+    ensure we are talking about the type characteristics visible inside the
+    function body, rather than the characteristics visible to the caller. Of
+    course compilers are encouraged to signal the error as soon as possible
+
+                Static Semantics
+
+    Within an extended_return_statement, the *return object* is declared with
+    the given identifier, with subtype defined by the subtype_indication.
+
+                Dynamic Semantics
+
+    For the execution of a simple_return_statement, the expression (if any) is
+    first evaluated and converted to the result subtype.
+
+    If the function is return-by-reference, then a check is made that the
+    return expression is one of the following:
+
+       * a name that denotes an object view whose accessibility level is not
+         deeper than that of the master that elaborated the function body; or
+
+       * a parenthesized expression or qualified_expression whose operand is
+         one of these kinds of expressions.
+
+    The exception Program_Error is raised if this check fails.
+
+    If the function is not return-by-reference, the value of the return
+    expression becomes the initial value of an anonymous *return object*.
+
+    For the execution of an extended_return_statement, the subtype_indication
+    is elaborated. This creates the nominal subtype of the return object. If
+    there is a return 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 subtype
+    (see 3.3.1). The handled sequence of statements, if any, is then executed.
+
+    If the result type of a function is a specific tagged type:
+
+       * If it is limited, or the function is return-by-reference, a check
+         is made that the tag of the value of the return expression, if any,
+         identifies the result type. Constraint_Error is raised if this check
+         fails;
+
+       * Otherwise, the 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.
+
+    AARM Reason: These rules ensure 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,
+    if not return-by-reference, allows the caller to allocate the appropriate
+    amount of space to hold the value being returned (assuming there are no
+    discriminants).
+
+    For a return-by-reference function the result is returned by reference;
+    that is, the function call denotes an aliased constant view of the
+    (preexisting) object denoted by the return expression. For a non
+    return-by-reference function, the return object is a newly created object,
+    and the function call denotes that object.
+
+    Finally, a transfer of control is performed which completes the execution
+    of the construct to which the return_statement applies, and returns to the
+    caller.
+
+                      Examples
+
+    Examples of return statements:
+
+         return;                         -- in a procedure body, entry_body,
+                                         -- accept_statement, or extended_return_statement
+
+         return Key_Value(Last_Index);   -- in a function body
+
+
+Add after 8.1(4):
+
+    * an extended_return_statement;
+
+
 !example
 
 Here is an example of a function with a limited result type
@@ -217,9 +375,9 @@
 Because the implementation needs to create the result object in a place
 or a storage pool determined by the caller, it is important that
 the declaration of the object be distinguished in some way.
-By declaring it as part of an extended return statement, we have
+By declaring it as part of an extended return statement, we have a
 way for the programmer to indicate that
-this is *the* object to be returned.  Clearly we don't
+this is *the* object to be returned. Clearly we don't
 want to allow extended return statements to be nested.
 
 Because it may be necessary to do some computing before deciding
@@ -260,7 +418,7 @@
 The proposed syntax for extended return statements was discussed a year or so
 ago, but when this AI was first written up, we proposed instead a revised
 object declaration syntax where the word "return" was used almost like the word
-"constant," as a qualifier.  This was somewhat more economical in terms of
+"constant," as a qualifier. This was somewhat more economical in terms of
 syntax and indenting, but was not felt to be as clear semantically as this
 current syntax.
 
@@ -279,7 +437,7 @@
 The implementation of the return-by-reference function is the same as
 the existing capability for functions whose result type is return-by-reference.
 The difference is that this would be permitted for types that are not
-"return-by-reference," and perhaps not even limited.  In particular,
+"return-by-reference," and perhaps not even limited. In particular,
 an accessibility check is performed at the point of the return statement,
 and a reference to the object associated with the return expresion is
 returned to the caller.
@@ -295,6 +453,7 @@
 routine, which uses it for the "return" object.
 
 If the result subtype is unconstrained, then there are two basic possibilities:
+(NOTE: We have disallowed this case for now.)
 
    1) The target object's (nominal) subtype is definite, and either constrained or
       the size of the object is independent of the constraints (e.g. allocate-the-max
@@ -327,11 +486,11 @@
 In either case, the function would return the address of the new
 object.
 
-A "bare" storage pool may not be enough in general.  If the type
+A "bare" storage pool may not be enough in general. If the type
 has any task parts, then these tasks must be placed on an activation
-list determined by the calling context.  They may also be linked onto a
+list determined by the calling context. They may also be linked onto a
 master record of some sort, unless this is deferred until
-activation occurs.  Note that the tasks cannot be activated
+activation occurs. Note that the tasks cannot be activated
 until after returning from the call, since they may have
 to be activated in conjunction with other tasks having the
 same master.
@@ -356,6 +515,32 @@
   - the associated master,
   - a cleanup list
 
+TAKING ADVANTAGE OF RESTRICTION TO CONSTRAINED LIMITED RESULT SUBTYPES
+
+In the current proposal, we have disallowed unconstrained limited result
+subtypes to simplify implementation. By "limited" we mean limited from the
+function body perspective, not from the caller perspective.
+
+With this limitation, the caller can always preallocate space for the
+"return object" when limited, and treat the "result" somewhat like an OUT
+parameter. In addition, the caller can do default initialization for all
+limited subcomponents. Nonlimited controlled components can still require
+some fancy footwork, since they can be explicitly initialized, so default
+initializing them would be inappropriate. But compilers already have to
+deal with returning non-limited controlled objects, so presumably this
+won't create an insurmountable burden.
+
+DEALING WITH EXCEPTIONS
+
+There was some concern about what would happen if an exception was
+propagated by an extended return statement, and then the same or some other
+extended return statement was reentered. I don't see a real problem. The
+return object doesn't really exist outside the function until the function
+returns, so it can be restored to its initial state on call of the function
+if an exception is propagated from an extended return statement. Once
+restored to its initial state, there seems no harm in starting over in
+another extended_return_statement.
+
 IMPLEMENTATION APPROACH FOR ANONYMOUS ACCESS RESULT TYPE
 
 For anonymous access result types, a similar approach would
@@ -425,7 +610,7 @@
      the storage pool passed in must not outlive the function declaration.
      This would imply that the function could safely set the access
      discriminants to point to objects with an accessibility level
-     no deeper than the function declaration.  This is similar
+     no deeper than the function declaration. This is similar
      to the test performed on return-by-reference now (6.5(17-20)).
 
      With this restriction, no accessibilty level needs to be passed
@@ -498,6 +683,8 @@
 form of the proposal.
 
 !ACATS test
+
+ACATS(s) tests need to be created for these features.
 
 !appendix
 

Questions? Ask the ACAA Technical Agent