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

Differences between 1.2 and version 1.3
Log of other versions for file 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