CVS difference for ai05s/ai05-0103-1.txt
--- ai05s/ai05-0103-1.txt 2008/08/14 03:19:24 1.2
+++ ai05s/ai05-0103-1.txt 2008/10/25 04:53:14 1.3
@@ -1,16 +1,17 @@
-!standard 6.5(5.2/2) 08-08-13 AI05-0103-1/02
+!standard 6.5(5.2/2) 08-08-14 AI05-0103-1/03
!class binding interpretation 08-06-15
!status work item 08-06-15
!status received 06-04-25
!priority Low
!difficulty Medium
!qualifier Omission
-!subject Return statements should require static compatibility
+!subject Return statements should require at least static compatibility
!summary
The subtype_indication in an extended_return_statement must be statically
-compatible with the result subtype of the function.
+compatible with the result subtype of the function, and for elementary
+types, must statically match the result type.
!question
@@ -72,13 +73,15 @@
The existing stricter checking for elementary types is preserved; this
disallows the following (arguably reasonable) example:
- function F1 return Integer'Base is
+ function F1 return Integer is
begin
return X : Natural do -- illegal
...;
end return;
end F1;
+Recall that static compatibility of constrained scalar types does not
+imply static matching as it does for other constrained types.
There would be no definitional problems associated with omitting
"; if the result type of the function is elementary, then
the two subtypes shall statically match"
@@ -86,21 +89,19 @@
justification for changing the language to allow cases such
as the preceding example.
-[Editor's note: Note that the more likely example with F1 returning
-Integer would fail static compatibility, as Integer is constrained.
-A similar example could be constructed with types like Float
-(which are considered unconstrained).]
-
-[Editor's note 2: This also makes access constraints illegal. For example:
+[Editor's note: 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;
-In this case, it is better to put the constraint into the allocator
-(else extra checks are needed on the allocator), so this does not
-lose any capability.]
+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
+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.]
Is "static compatibility" well defined in the case where the the
Questions? Ask the ACAA Technical Agent