CVS difference for ai05s/ai05-0053-1.txt
--- ai05s/ai05-0053-1.txt 2007/05/26 01:44:00 1.1
+++ ai05s/ai05-0053-1.txt 2007/10/31 02:24:49 1.2
@@ -1,4 +1,4 @@
-!standard G.3.1 07-05-15 AI05-0053-1/01
+!standard 6.5(2.1/2) 07-10-30 AI05-0053-1/02
!class binding interpretation 07-05-15
!status work item 07-05-15
!status received 07-05-07
@@ -9,7 +9,7 @@
!summary
-*TBD*
+Ban aliased return objects.
!question
@@ -18,15 +18,15 @@
This introduces a number of problems.
-How are these problems to be resolved?
+How are these problems to be resolved? (Ban aliased return objects)
!recommendation
-Not clear. Ban aliased return objects? See discussion for ideas.
+Ban aliased return objects.
!wording
-*TBD*
+In 6.5(2.1) (syntax for extended_return_statement), delete "[aliased]".
!discussion
@@ -118,15 +118,22 @@
How should these problems be addressed?
-One could simply change the syntax to disallow aliased extended return
-objects, but that's a fairly major incompatibility.
+It has been decided to solve these problems by changing the syntax
+so that extended return objects cannot be declared with the reserved
+word "aliased".
+
+Technically speaking, this isn't really much of a change because the
+keyword "aliased" really had no meaning here. 3.10 defines which
+objects are aliased, and that list was never updated to include
+return objects.
-It would probably be better to explicitly state the Unchecked_Access
-"clarification" described above and then add a runtime check which
+We could have instead explicitly stated the Unchecked_Access
+"clarification" described above and added a runtime check which
raises Program_Error when X'Access is evaluated during the execution
of the preceding example.
-How precise should the condition of that runtime check be?
+However, it would have been hard to define what the predicate of that check
+should be.
Perhaps the check fails during the evaluation of Some_Object'Access
(or Some_Object'Unchecked_Access) if Some_Object is an aliased extended
@@ -147,8 +154,26 @@
only a boolean) on the off chance that a function's body *might*
contain this problematic construct.
+These complications tell us that aliased return objects are not worth
+the trouble; thus we selected the simple solution.
+
+!corrigendum 6.5(2.1/2)
+
+@drepl
+@xcode<@fa<extended_return_statement ::=
+ >@ft<@b<return>>@fa< defining_identifier : [>@ft<@b<aliased>>@fa<] return_subtype_indication [:= expression] [>@ft<@b<do>>@fa<
+ handled_sequence_of_statements
+ >@ft<@b<end return>>@fa<];>>
+@dby
+@xcode<@fa<extended_return_statement ::=
+ >@ft<@b<return>>@fa< defining_identifier : return_subtype_indication [:= expression] [>@ft<@b<do>>@fa<
+ handled_sequence_of_statements
+ >@ft<@b<end return>>@fa<];>>
+
!ACATS test
+There probably would be value in a B-Test to ensure that 'aliased' is not
+allowed, as it *is* in the syntax of the Amendment.
!appendix
Questions? Ask the ACAA Technical Agent