CVS difference for ai05s/ai05-0053-1.txt

Differences between 1.1 and version 1.2
Log of other versions for file 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