CVS difference for ais/ai-10318.txt
--- ais/ai-10318.txt 2004/06/10 05:39:58 1.3
+++ ais/ai-10318.txt 2004/07/27 23:01:09 1.4
@@ -1,7 +1,32 @@
-!standard 03.03.01(02) 04-04-05 AI95-00318-02/02
-!standard 06.05.00(17)
-!standard 06.05.00(18)
+!standard 03.10.02(13) 04-07-02 AI95-00318-02/03
+!standard 06.01(13)
+!standard 06.03.01(16)
+!standard 06.05(02)
+!standard 06.05(03)
+!standard 06.05(04)
+!standard 06.05(05)
+!standard 06.05(06)
+!standard 06.05(07)
+!standard 06.05(08)
+!standard 06.05(09)
+!standard 06.05(10)
+!standard 06.05(11)
+!standard 06.05(12)
+!standard 06.05(13)
+!standard 06.05(14)
+!standard 06.05(15)
+!standard 06.05(16)
+!standard 06.05(17)
+!standard 06.05(18)
+!standard 06.05(19)
+!standard 06.05(20)
+!standard 06.05(21)
+!standard 06.05(22)
+!standard 06.05(24)
+!standard 08.01(4)
!class amendment 02-10-09
+!status Amendment 200Y 04-07-02
+!status ARG Approved 9-0-2 04-06-17
!status work item 03-05-23
!status received 02-10-09
!priority Medium
@@ -19,14 +44,13 @@
when a function returns a complex object, a controlled object, etc.
The existing ability to return by reference is replaced by an
-ability to have an anonymous access type as a return type, and
-allowing implicit dereference of calls on such functions.
+ability to have an anonymous access type as a return type.
!problem
-We already have a proposal for allowing aggregates of a limited type,
-by requiring that the aggregate be built directly in the target object.
-rather than being copied into the target.
+We already have a proposal (AI-287) for allowing aggregates of a limited type,
+by requiring that the aggregate be built directly in the target object rather
+than being copied into the target.
But aggregates can only be used with non-private types. Limited
private types could not be initializable at their declaration point.
@@ -55,12 +79,12 @@
The capability to return-by-reference could be useful for non-limited types,
but it becomes even more useful if a call on such a function could be treated
-as a variable, so it could be used on the left-hand side of an assignment. An
-alternative which provided these capabilities without introducing the
-conceptual oddity of return-by-reference would be welcome. If a function could
-return an access value which was then implicitly dereferenced at the call site,
-the effect of return-by-reference could be accomplished, but with a model that
-is more consistent with other parts of the language.
+as a variable, so it could be used on the left-hand side of an assignment.
+These capabilities exist in the language without introducing the
+conceptual oddity of return-by-reference. A function returning
+an access value allows the effect of return-by-reference, and doesn't
+require changing the language, at the cost of a bit of extra verbosity in
+some cases (the need to dereference the result).
!proposal
@@ -74,11 +98,7 @@
*access result type*. The accessibility level of an access result type is that
of the declaration containing the parameter_and_result_profile.
-A call of a function with an access result type may be implicitly
-dereferenced in any context where a name is permitted, other than
-as the operand of a type conversion.
-
-------------
An extended syntax for the return statement is proposed:
@@ -127,6 +147,8 @@
where a "name" that denotes an object or value is permitted, except as the
right hand side of an assignment statement.
+This proposal assumes that AI-287 is adopted; it does not repeat the changes
+needed to allow function_calls in the contexts listed above.
!wording
@@ -136,45 +158,6 @@
type (see 6.5) is the same as that of the associated function or
access-to-subprogram type.
-Modify 4.1(2):
-
- name ::= ... {| implicit_function_call_dereference}
-
-
-Add after 4.1(6):
-
- implicit_function_call_dereference ::= function_call
-
- The name in an implicit_dereference or an explicit_dereference
- shall not be an implicit_function_call_dereference.
-
-Modify 4.1(8) as follows:
-
- The name {or function_call} in a *dereference* ([either] an
- implicit_dereference[ or]{,} an explicit_dereference{, or an
- implicit_function_call_dereference}) is expected to be of any access
- type. {The function_name or function_prefix of the function_call of
- an implicit_function_call_dereference shall denote a function with
- an anonymous access result type.}
-
- AARM Note:
- We don't allow a dereference of an implicit dereference. We provide
- implicit dereferences in a prefix, or as the result of calling
- a function with an anonymous access type as result type.
-
-Modify 4.1(13):
- The evaluation of a dereference consists of the evaluation of the name {or
- function_call} and the determination of the object or subprogram that is
- designated by the value of the name {or function_call}. A check is made
- that [the value of the name] {this value} is not the null access value.
- Constraint_Error is raised if this check fails. The dereference denotes
- the object or subprogram denoted by [the value of the name] {this value}.
-
-Add after 4.6(7):
-
- The operand of a conversion shall not be an
- implicit_function_call_dereference.
-
Change 6.1(13) to:
parameter_and_result_profile ::=
@@ -221,11 +204,11 @@
function is frozen (see 13.14), the result subtype shall be constrained.
AARM NOTE:
- This second rule is not a necessary restriction, but simplifies implementation
+ This rule is not a necessary restriction, but simplifies implementation
dramatically, since it means the caller can 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.
+ etc.
AARM Ramification:
Note that this rule is defined at the point where a function is frozen
@@ -330,11 +313,16 @@
Node.Succ := Next_Mode;
end return;
+The new rule added before 7.5(2) by AI-287 should say:
+...unless it is an aggregate, a function_call, or a parenthesized...
+
+Similarly, the new rule added after 7.5(8) and the replacement note of 7.5(9)
+of AI-287 should say "aggregate or function_call" in each occurrence.
+
Add after 8.1(4):
* an extended_return_statement;
-
!example
Here is an example of a function with a limited result type
@@ -359,9 +347,8 @@
end return;
end Make_Obj;
-Here is an abstraction which takes advantage of the implicit dereference
-of functions with access result types, to support an extensible array
-abstraction (aka vector):
+Here is an abstraction which uses functions with access result types, to
+support an extensible array abstraction (aka vector):
generic
type Element is private;
@@ -417,13 +404,13 @@
-- Add one to each of the elements with indices up to Max/2
for I in 1..Max/2 loop
- Elem(X, I) := Elem(X, I) + 1; -- Using implicit deref
+ Elem(X, I).all := Elem(X, I).all + 1;
end loop;
-- Now print out the table
for I in 1..Last(X) loop
Ada.Text_IO.Put_Line(Integer'Image(I) & " => " &
- Integer'Image(Elem(X, I))); -- Again using implicit deref
+ Integer'Image(Elem(X, I).all));
end loop;
Set_Empty(X); -- All done
@@ -499,11 +486,10 @@
current syntax.
We have eliminated the capability for returning by reference, in favor
-of returning a value of an anonymous access type, coupled with implicit
-dereference of a call on such a function. An alternative proposal (AI-318-1)
-proposed to make return-by-reference a separate capability, triggered
-by the presence of the reserved word "ALIASED" in the function profile.
-This was felt by some reviewers to be enshrining the confusing notion
+of returning a value of an anonymous access type. An alternative proposal
+(AI-318-1) proposed to make return-by-reference a separate capability,
+triggered by the presence of the reserved word "ALIASED" in the function
+profile. This was felt by some reviewers to be enshrining the confusing notion
of return-by-reference, which earlier had been buried in a discussion
of certain limited types. Furthermore, the implementation model of
return by reference was clearly to return a "reference" (effectively an access
@@ -551,11 +537,6 @@
a run-time model point of view. There is no need for any (new) run-time
accessibility checking.
-Supporting implicit dereference of functions with an anonymous access result
-type will require some work in the overloading phase, but anonymous access
-types are already implicitly convertible to various named access types,
-so this is essentially adding implicit "convertibility" to the designated type.
-
DEALING WITH EXCEPTIONS
There was some concern about what would happen if an exception were
@@ -566,6 +547,322 @@
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.
+
+
+!corrigendum 3.10.2(13)
+
+@dinsa
+@xbullet<The accessibility level of the anonymous access type of an access
+parameter is the same as that of the view designated by the actual. If the
+actual is an @fa<allocator>, this is the accessibility level of the execution
+of the called subprogram.>
+@dinst
+@xbullet<The accessibility level of the anonymous access type of an access
+result type (see 6.5) is the same as that of the associated function or
+access-to-subprogram type.>
+
+!corrigendum 6.1(13)
+
+@drepl
+@xcode<@fa<parameter_and_result_profile ::= [formal_part] >@ft<@b<return>>@fa< subtype_mark>>
+@dby
+@xcode<@fa<parameter_and_result_profile ::=
+ [formal_part] >@ft<@b<return>>@fa< subtype_mark
+ | [formal_part] >@ft<@b<return>>@fa< access_definition>>
+
+
+!corrigendum 6.3.1(16)
+
+@drepl
+Two profiles are @i<mode conformant> if they are type-conformant, and
+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,
+corresponding parameters have identical modes, and, for access parameters or
+access result types, the designated subtypes statically match.
+
+!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 ::=
+ >@ft<@b<return>>@fa< identifier : [>@ft<@b<aliased>>@fa<] >@ft<@i<return>>@fa<_subtype_indication [:= expression] [>@ft<@b<do>>@fa<
+ handled_sequence_of_statements
+ >@ft<@b<end return>>@fa<];>>
+
+@xcode<@fa<return_subtype_indication ::= subtype_indication | access_definition>>
+
+!corrigendum 6.5(03)
+
+@drepl
+The @fa<expression>, if any, of a @fa<return_statement> is called the @i<return
+expression>. The @i<result subtype> of a function is the subtype denoted by the
+@fa<subtype_mark> after the reserved word @b<return> in the profile of the
+function. The expected type for a return expression is the result type of the
+corresponding function.
+@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<return_statement> is called the @i<return expression>. The expected type
+for a return expression is the result type of the corresponding function.
+
+!corrigendum 6.5(04)
+
+@drepl
+A @fa<return_statement> shall be within a callable construct, and it @i<applies
+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
+If the result subtype of a function is limited at the point where the
+function is frozen (see 13.14), the result subtype shall be constrained.
+
+A @fa<return_statement> shall be within a callable construct, and it 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.
+
+!corrigendum 6.5(05)
+
+@drepl
+A function body shall contain at least one @fa<return_statement> that applies
+to the function body, unless the function contains @fa<code_statement>s. A
+@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
+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
+it applies to a function body. An @fa<extended_return_statement> shall apply to
+a function body.
+
+If the result subtype of a function is defined by a @fa<subtype_mark>, the
+@fa<return_subtype_indication> of an @fa<extended_return_statement> that
+applies to the function body shall be a @fa<subtype_indication>. The type of
+the @fa<subtype_indication> shall be the result type of the function. If the
+result subtype of the function is constrained, then the subtype defined by the
+@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.
+
+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
+subtype defined by the @fa<access_definition> shall statically match the result
+subtype of the function. The accessibility level of this anonymous access
+subtype is that of the result subtype.
+
+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.
+
+@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
+@i<return>@fa<_subtype_indication>.
+
+!corrigendum 6.5(06)
+
+@drepl
+For the execution of a @fa<return_statement>, the @fa<expression> (if any) is
+first evaluated and converted to the result subtype.
+@dby
+For the execution of an @fa<extended_return_statement>, the
+@fa<subtype_indication> is elaborated. This creates 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
+initialized by default as for a stand-alone object of its nominal subtype
+(see 3.3.1). If the nominal subtype is indefinite, the return object is
+constrained by its initial value. The handled sequence of statements, if
+any, is then executed.
+
+For the execution of a @fa<simple_return_statement>, the expression (if any) is
+first evaluated and converted to the result subtype to become the value of
+the anonymous @i<return object>.
+
+!corrigendum 6.5(07)
+
+@ddel
+If the result type is class-wide, then the tag of the result is the tag of the
+value of the @fa<expression>.
+
+!corrigendum 6.5(08)
+
+@drepl
+If the result type is a specific tagged type:
+@dby
+If the result type of a function is a specific tagged type, the
+tag of the return object is that of the result type.
+
+!corrigendum 6.5(09)
+
+@ddel
+@xbullet<If it is limited, then a check is made that the tag of the value of
+the return expression identifies the result type. Constraint_Error is raised
+if this check fails.>
+
+!corrigendum 6.5(10)
+
+@ddel
+@xbullet<If it is nonlimited, then the tag of the result is that of the result
+type.>
+
+!corrigendum 6.5(11)
+
+@ddel
+A type is a @i<return-by-reference> type if it is a descendant of one of the
+following:
+
+!corrigendum 6.5(12)
+
+@ddel
+@xbullet<a tagged limited type;>
+
+!corrigendum 6.5(13)
+
+@ddel
+@xbullet<a task or protected type;>
+
+!corrigendum 6.5(14)
+
+@ddel
+@xbullet<a nonprivate type with the reserved word @b<limited> in its
+declaration;>
+
+!corrigendum 6.5(15)
+
+@ddel
+@xbullet<a composite type with a subcomponent of a return-by-reference type;>
+
+!corrigendum 6.5(16)
+
+@ddel
+@xbullet<a private type whose full type is a return-by-reference type.>
+
+!corrigendum 6.5(17)
+
+@ddel
+If the result type is a return-by-reference type, then a check is made that the
+return expression is one of the following:
+
+!corrigendum 6.5(18)
+
+@ddel
+@xbullet<a @fa<name> that denotes an object view whose accessibility level is
+not deeper than that of the master that elaborated the function body; or>
+
+!corrigendum 6.5(19)
+
+@ddel
+@xbullet<a parenthesized expression or @fa<qualified_expression> whose operand
+is one of these kinds of expressions.>
+
+!corrigendum 6.5(20)
+
+@ddel
+The exception Program_Error is raised if this check fails.
+
+!corrigendum 6.5(21)
+
+@ddel
+For a function with a return-by-reference result type the result is returned by
+reference; that is, the function call denotes a constant view of the object
+associated with the value of the return expression. For any other function, the
+result is returned by copy; that is, the converted value is assigned into an
+anonymous constant created at the point of the @fa<return_statement>, and the
+function call denotes that object.
+
+!corrigendum 6.5(22)
+
+@drepl
+Finally, a transfer of control is performed which completes the
+execution of the 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,
+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, entry_body, or accept_statement>>
+@b<return> Key_Value(Last_Index); -- @ft<@i<in a function body>>>
+@dby
+@xcode<@b<return>; -- @ft<@i<in a procedure body, entry_body,>>
+ -- @ft<@i<accept_statement, or extended_return_statement>>>
+
+@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>>
+ Node.Value := Result;
+ Node.Succ := Next_Mode;
+@b<end return>;>
+
+!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
+!comment function_calls and aggregates.
+
+@dinsb
+If a tagged record type has any limited components, then the reserved word
+@b<limited> shall appear in its @fa<record_type_definition>.
+@dinst
+In the following contexts, an @fa<expression> of a limited
+type is not permitted unless it is a @fa<function_call>
+or a parenthesized @fa<expression> or @fa<qualified_expression> whose operand
+is permitted by this rule:
+@xbullet<the initialization @fa<expression> of an @fa<object_declaration> (see 3.3.1)>
+@xbullet<the @fa<default_expression> of a component_declaration (see 3.8)>
+@xbullet<the @fa<expression> of a @fa<record_component_association> (see 4.3.1)>
+@xbullet<the @fa<expression> for an @fa<ancestor_part> of an @fa<extension_aggregate> (see 4.3.2)>
+@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 @fa<allocator> (see 4.8)>
+@xbullet<the @fa<expression> of a @fa<return_statement> (see 6.5)>
+@xbullet<the @fa<default_expression> or actual parameter for a formal object
+of mode @b<in> (see 12.4)>
+
+!corrigendum 7.5(8)
+
+@dinsa
+There are no predefined equality operators for a limited type.
+@dinst
+@i<@s8<Implementation Requirements>>
+
+For a @fa<function_call> of a by-reference type whose full view
+is limited 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: >>
+@dby
+@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 8.1(4)
+
+@dinsa
+@xbullet<a @fa<loop_statement>;>
+@dinst
+@xbullet<an @fa<extended_return_statement>;>
+
!ACATS test
Questions? Ask the ACAA Technical Agent