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

--- ai05s/ai05-0103-1.txt	2008/10/25 04:53:14	1.3
+++ ai05s/ai05-0103-1.txt	2009/03/10 03:49:58	1.4
@@ -1,5 +1,7 @@
-!standard 6.5(5.2/2)                                      08-08-14  AI05-0103-1/03
+!standard 6.5(5.2/2)                                      09-03-09  AI05-0103-1/04
 !class binding interpretation 08-06-15
+!status Amendment 201Z 09-02-21
+!status ARG Approved  8-0-0  09-02-21
 !status work item 08-06-15
 !status received 06-04-25
 !priority Low
@@ -45,7 +47,7 @@
 Now An_Access is not constrained as defined by 3.10(14/1) [the designated
 subtype is an unconstrained array]. Thus the first part of 6.5(5.2/2) does
 not apply, and no matching is required. So it appears that we've succeeded
-in returning null from a null-excluding function. Ouch.
+in returning null from a null-excluding function. Is this intended? (No.)
 
 !wording
 
@@ -89,7 +91,7 @@
 justification for changing the language to allow cases such
 as the preceding example.
 
-[Editor's note: This also makes access constraints illegal. For example:
+This also makes access constraints illegal. For example:
    function F2 return Acc_String is
    begin
      return X : Acc_String(1..10) do -- illegal
@@ -101,10 +103,10 @@
 it (or, in the case of 'Access, the aliased object itself). So no capability
 is lost by this restriction. The extra checks that would be needed to 
 implement this constraint buy little, especially as they are not required
-by the specification of the function.]
+by the specification of the function.
 
 
-Is "static compatibility" well defined in the case where the the
+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
@@ -113,7 +115,29 @@
 if it were determined that static compatibility is only defined for two
 subtypes of the same type), then further wording changes are needed.
 
---!corrigendum 6.5(5.2/2)
+!corrigendum 6.5(5.2/2)
+
+@drepl
+@xbullet<If the result subtype of the function is defined by a
+@fa<subtype_mark>, the @fa<return_subtype_indication> 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 an
+@fa<expression>.>
+@dby
+@xbullet<If the result subtype of the function is defined by a
+@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
+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
+@fa<expression>.>
+
 
 !ACATS Test