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
Questions? Ask the ACAA Technical Agent