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

--- ai05s/ai05-0053-1.txt	2008/03/07 06:15:19	1.4
+++ ai05s/ai05-0053-1.txt	2008/05/10 05:14:33	1.5
@@ -1,4 +1,4 @@
-!standard 3.10(9/2)                                08-02-25    AI05-0053-1/04
+!standard 3.10(9/2)                                08-04-09    AI05-0053-1/05
 !standard 6.5(2.1/2)
 !class binding interpretation 07-05-15
 !status ARG Approved  8-0-0  08-02-09
@@ -21,11 +21,11 @@
 
 This introduces a number of problems.
 
-How are these problems to be resolved? (Ban aliased return objects)
+How are these problems to be resolved? (Eliminate aliased return objects.)
 
 !recommendation
 
-Ban aliased return objects (except for immutably limited types).
+Eliminate aliased return objects (except for immutably limited types).
 
 !wording
 
@@ -41,7 +41,7 @@
    aliased, as is the return object of an extended_return_statement
    (see 6.5) that is of an immutably limited type.
 
-In 6.5(2.1) (syntax for extended_return_statement), delete "[aliased]".
+In 6.5(2.1/2) (syntax for extended_return_statement), delete "[aliased]".
    
 !discussion
 
@@ -78,7 +78,7 @@
 contiguous dope vector.
 
 This implementation model worked for Ada95 and it was not
-the intention of the Ada05 designers to invalidate this approach.
+the intention of the Ada 2005 designers to invalidate this approach.
 
 If it is possible to construct an aliased view of an object which
 lacks a contiguous dope vector, then things can go downhill rapidly.
@@ -120,10 +120,12 @@
   
 There is also a considerably more obscure problem involving object identity.
 In this example, 
+
   subtype Zero_Sized is String (1 .. Report.Ident_Int (0)); 
   X1, Y1 : Zero_Sized := Some_Function;
   X2, Y2 : aliased Zero_Sized;
-, it is ok if X1'Address = Y1'Address but it is not ok
+
+It is ok if X1'Address = Y1'Address but it is not ok
 if X2'Access = Y2'Access. If we can somehow construct X1'Access and Y1'Access,
 and if they must be distinct, then some implementations might have a problem.
 
@@ -155,7 +157,6 @@
 to look through private types to see if the completion "has the
 reserved word *limited*". The rule is therefore expressed in terms
 of "an explicitly limited record type" instead.
-
 
 We could have instead explicitly stated the Unchecked_Access
 "clarification" described above and added a runtime check which