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