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

--- ai05s/ai05-0103-1.txt	2008/06/16 04:35:36	1.1
+++ ai05s/ai05-0103-1.txt	2008/08/14 03:19:24	1.2
@@ -1,16 +1,16 @@
-!standard 6.5(5.2/2)                                      08-06-15  AI05-0103-1/01
+!standard 6.5(5.2/2)                                      08-08-13  AI05-0103-1/02
 !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 matching for all named access types
+!subject Return statements should require static compatibility
 
 !summary
 
-The subtype_indication in an extended_return_statement must statically match
-the result type of the function if the type is an access type.
+The subtype_indication in an extended_return_statement must be statically
+compatible with the result subtype of the function.
 
 !question
 
@@ -53,28 +53,64 @@
 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
 subtype_indication shall be covered by the result type of the function.
-If the result subtype of the function is {an access type or is} constrained,
-then the subtype defined by the subtype_indication shall [also be constrained
-and] shall statically match this result subtype.
-{Otherwise, if}[If] the result subtype of the function is unconstrained {and not
-an access type}, then the subtype defined by the subtype_indication shall
-be a definite subtype, or there shall be an expression.
+[If the result subtype of the function is constrained, then the]{The} subtype
+defined by the subtype_indication shall [also ]be {statically compatible
+with the result subtype of the function; if the result type of the function
+is elementary, the two subtypes }[constrained and ]shall statically
+match[ this result subtype]. If the result subtype of the function is
+[unconstrained]{indefinite}, then the subtype defined
+by the subtype_indication shall be a definite subtype, or there shall be an
+expression.
 
 !discussion
 
-We require static matching for all access types, because whether or not they
-are constrained depends on the designated subtype (which should match here),
-and not on the characteristics of the type.
-
-Note that 6.5(5.3/2) require static matching for all anonymous access types;
-it would be strange to have a different rule for named access types.
-
-[Should there have been an exception to both rules class-wide cases? We generally
-have tried for that, but not here for some reason.]
-
-We drop the part about the return subtype_indication being constrained, as that
-is implied by static matching for non-access types (and is irrelevant and possibly
-incorrect for access types).
+This new wording correctly handles the cases involving null exclusions
+because these are handled correctly in the definition of static compatibility.
+The new wording does not need to talk about "constrained" and "unconstrained"
+as that is included in the definition of static compatibility.
+
+The existing stricter checking for elementary types is preserved; this
+disallows the following (arguably reasonable) example:
+
+   function F1 return Integer'Base is
+   begin
+     return X : Natural do -- illegal
+       ...;
+     end return;
+   end F1;
+
+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"
+from the wording above, but there does not seem to be adequate
+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:
+   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.]
+
+
+Is "static compatibility" well defined in the case where the 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.
 
 --!corrigendum 6.5(5.2/2)