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

--- ai05s/ai05-0103-1.txt	2009/03/10 03:49:58	1.4
+++ ai05s/ai05-0103-1.txt	2009/05/31 06:27:32	1.5
@@ -1,4 +1,4 @@
-!standard 6.5(5.2/2)                                      09-03-09  AI05-0103-1/04
+!standard 6.5(5.2/2)                                      09-05-30  AI05-0103-1/05
 !class binding interpretation 08-06-15
 !status Amendment 201Z 09-02-21
 !status ARG Approved  8-0-0  09-02-21
@@ -51,7 +51,7 @@
 
 !wording
 
-Modify 6.5(5.2) (as previous modified by AI05-0032-1):
+Modify 6.5(5.2/2) (as previously modified by AI05-0032-1):
 
 If the result subtype of the function is defined by a subtype_mark, the
 return_subtype_indication shall be a subtype_indication. The type of the
@@ -92,12 +92,14 @@
 as the preceding example.
 
 This also makes access constraints illegal. For example:
+
    function F2 return Acc_String is
    begin
      return X : Acc_String(1..10) do -- illegal
        ...
      end return;
    end F2;
+
 Unlike composite types, this constraint is not needed nor used to determine
 the shape of the designated object. That comes from the allocator that created
 it (or, in the case of 'Access, the aliased object itself). So no capability
@@ -108,12 +110,11 @@
 
 Is "static compatibility" well defined in the case where the
 type of the first subtype is covered by, but is not the same as,
-the type of the second subtype? Pending the resolution of AI05-0057, all
-we really depend on is a rule that if T is the first named subtype of a
-specific tagged type, then any subtype of any type that is covered by T
-is statically compatible with T'Class. If that is not the case (e.g.,
-if it were determined that static compatibility is only defined for two
-subtypes of the same type), then further wording changes are needed.
+the type of the second subtype? All we really depend on is a rule that
+if T is the first named subtype of a specific tagged type, then any subtype
+of any type that is covered by T is statically compatible with T'Class.
+That appears to be the case with the current definition of "static
+compatibility".
 
 !corrigendum 6.5(5.2/2)
 
@@ -132,7 +133,7 @@
 @fa<subtype_mark>, the @fa<return_subtype_indication> shall be a
 @fa<subtype_indication>. The type of the @fa<subtype_indication> shall be covered by
 the result type of the function. The subtype defined by the @fa<subtype_indication>
-shall statically compatible with the result subtype of the function; if the result
+shall be statically compatible with the result subtype of the function; if the result
 type of the function is elementary, the two subtypes shall statically match.
 If the result subtype of the function is indefinite, then the subtype defined
 by the @fa<subtype_indication> shall be a definite subtype, or there shall be an