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

Differences between 1.2 and version 1.3
Log of other versions for file ai05s/ai05-0050-1.txt

--- ai05s/ai05-0050-1.txt	2007/10/31 02:24:49	1.2
+++ ai05s/ai05-0050-1.txt	2008/06/14 07:05:32	1.3
@@ -1,4 +1,4 @@
-!standard 6.5(24/2)                              07-10-30    AI05-0050-1/02
+!standard 6.5(24/2)                              08-06-13    AI05-0050-1/03
 !class binding interpretation 07-05-04
 !status work item 07-05-04
 !status received 07-04-20
@@ -22,8 +22,8 @@
 the permission still applies to simple return statements and constrained
 return objects in extended return statements.
 
-All of these permissions apply to recursive calls (that is, calls to a function in
-a return statement).
+All of these permissions apply to recursive calls (that is, calls to a function
+in a return statement).
 
 !question
 
@@ -50,40 +50,25 @@
   
 with  
   
-  If a call on a function is used to provide the initial value of an object
-  of a composite type, then certain actions which would be performed
-  after the evaluation of the function call according to the canonical
-  semantics may be performed earlier.
-  
-  Consider the following three points at which the constraints of the
-  function result may become known:
-      - before calling the function
-        (in the case where the function result subtype is constrained)
-      
-      - during the elaboration of the return object declaration of an
-         extended_return_statement of the function
-      
-      - during the evaluation of the expression of a simple_return_statement
-        of the function
-   .
-   
-  If, at any of these points, it is determined that the function result
-  value will violate either the constraint of the subtype of the object
-  or some other intermediate constraint that would be checked during the
-  initialization of the object, then Constraint_Error may be raised at that
-  point.
-  
+  For a function call used to initialize a composite object with a constrained
+  nominal subtype:
+
+    - If the result subtype of the function is constrained, and does not match
+      that of the object, Constraint_Error may be raised before calling the
+      function.
+
+    - Otherwise (the result subtype of the function is unconstrained), if a
+      return statement is executed such that the return object is known to be
+      constrained, and this constraint does not match that of the object,
+      Constraint_Error may be raised at the point of the call (after abandoning
+      the execution of the function body).
+
   If the function call is used to provide the initial value of an
-  initialized allocator, then any calls to System.Storage_Pools.Allocate
-  (or System.Storage_Pools.Deallocate) which are associated with the
-  allocation of the object may be performed at any of these points, or at the
-  point of a non-value-returning exit from an extended return statement of the
-  function.
-  
-  These permissions do not apply in the case of an extended_return_statement
-  where the function result object is discriminated and is not known to be
-  constrained. 
-  
+  initialized allocator, then the call to System.Storage_Pools.Allocate
+  may occur at any time during the execution of the call.
+  If a return statement is left without a normal return, the result
+  object may be deallocated.
+
   AARM Notes
   
   These permissions apply transitively in the case of a function call
@@ -118,7 +103,7 @@
   , Constraint_Error may be raised in F1 before any calls to Some_Function
   are executed.
   
-  The "intermediate constraint" wording refers to cases like
+  Consider:
   
     declare
       type T is
@@ -170,10 +155,9 @@
   In all three of these cases, Constraint_Error may be raised in F1 before
   the execution of any calls to Some_Function.
   
-  The "These permissions do not apply" clause handles the
+  Note that these permissions do not apply in the
   case of an extended return object with mutable discriminants.
-  Because of this clause, the permissions of this section do not apply in
-  the following example
+  For example:
   
     declare
       type T (Is_Big : Boolean := True) is
@@ -186,7 +170,7 @@
        
       function F return T is
       begin
-        return X : T do
+        return X : T do -- X is unconstrained
          X.Big_Component := (others => 'Y');
          X := (Is_Big => False);
         end return;
@@ -197,13 +181,12 @@
       null;
     end;
       
-   and so Constraint_Error may not be raised (which is good).
+   and so Constraint_Error must not be raised (which is good).
    
-   Note that this revocation of permissions only applies in cases where
+   Note that this mutable-discriminant case only happens when
    in-place initialization is optional. This means that any difficulties
    associated with implementing in-place initialization without these
    permissions can be sidestepped.
-   
 
 !discussion
 
@@ -471,6 +454,10 @@
 
 !ACATS test
 
+As a permission, it is hard to write tests. But an ACATS C-Test should be
+constructed to ensure that a case such as the one in the discussion where
+mutable discriminants are changed from the "wrong" ones to the "right" ones
+does not raise a premature exception.
 
 !appendix
 
@@ -932,5 +919,137 @@
 otherwise single-tasking environment). A similar permission for Deallocate
 is also needed. I don't see any reason to clutter this one spot with something
 that needs to cover the entire language.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Saturday, June 14, 2008  1:30 AM
+
+[Commenting on version /03 of the AI.]
+
+...
+>   For a function call used to initialize a composite object with a constrained
+>   nominal subtype:
+> 
+>     - If the result subtype of the function is constrained, and does not match
+>       that of the object, Constraint_Error may be raised before calling the
+>       function.
+> 
+>     - Otherwise (the result subtype of the function is unconstrained), if a
+>       return statement is executed such that the return object is known to be
+>       constrained, and this constraint does not match that of the object,
+>       Constraint_Error may be raised at the point of the call (after abandoning
+>       the execution of the function body).
+
+This is much better than the previous effort.
+
+I think it would be good if the discussion pointed out that this permission still
+could raise an exception that the canonical semantics would not:
+
+     type Rec (D : Integer) is record ...
+
+     function F return Rec is
+     begin
+         return O : Rec(4) do -- (1)
+            if <some condition> then goto Different_Object; end if;
+         end return;
+        <<Different_Object>>
+         return O : Rec(5) do -- (2)
+            ...
+         end return;
+     end F;
+
+     O : Rec(5) := F;
+
+The permission above would raise an exception at (1). But since that object is
+never actually returned, and the object that is returned is the right shape, the
+full function call without the permission would succeed.
+
+I think this is OK (abandoning return statements is unusual and expensive because
+of the finalization issues), but we probably ought to mention it somewhere.
+
+>   If the function call is used to provide the initial value of an
+>   initialized allocator, then the call to System.Storage_Pools.Allocate
+>   may occur at any time during the execution of the call.
+>   If a return statement is left without a normal return, the result
+>   object may be deallocated.
+
+I think it would make more sense to try to address this more generally, as similar
+issues apply to failed allocators and probably any object declaration with
+coextensions (even if the allocator of the coextension succeeds). Admittedly,
+this case is easier (as finalization requires that the objects are finalized here,
+while the allocator case currently requires that they are *not* finalized), but
+it seems weird to fix a really unusual case without fixing the similar more
+likely cases.
+
+>   AARM Notes
+
+It's pretty obvious that these are the original Steve Baird notes (I don't think
+Bob starts sentences with commas!), they would benefit from a lot of Bob Duff
+pruning. I'm certain that we don't want two pages of weird examples in the AARM,
+particularly for a rule that seems fairly straigtforward.
+
+> !discussion
+
+The discussion section needs cleanup, too, as it still includes various
+alternatives that aren't of interest and lots of Bairdian prose with
+formatting that will not pass muster. If the AI authors don't keep these
+sections up-to-date, the editorial reviewers will make your editor do that.
+And I don't get paid enough to deal with the mountains of comments from the
+reviewers!!
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Saturday, June 14, 2008  1:49 AM
+
+> >   AARM Notes
+> 
+> It's pretty obvious that these are the original Steve Baird notes (I 
+> don't think Bob starts sentences with commas!), they would benefit 
+> from a lot of Bob Duff pruning. I'm certain that we don't want two 
+> pages of weird examples in the AARM, particularly for a rule that 
+> seems fairly straigtforward.
+
+To be a little more concrete, I think all that needs to be said in the AARM Notes is:
+
+  These permissions apply transitively in the case of a function call
+  which returns the value of another function call.
+
+[we don't need an example here, it's pretty obvious and there's one in the AI.]
+
+  These permissions do not apply in the case of an extended
+  return object with mutable discriminants. That's necessary because in that
+  case a return object can be created with the "wrong" discriminants and
+  then changed to the "right" discriminants later (but before returning).
+  We don't want this case raising an exception when the canonical semantics
+  will not do so.
+
+[words are better here than just giving an example, and again the example will
+be in the AI.]
+
+  It's still possible to write a program that will raise an exception using
+  this permission that would not in the canonical semantics. That could happen
+  if a return statement with the "wrong" discriminants or bounds is abandoned (via
+  an exception, or for an extended_return_statement, via an exit or goto statement),
+  and then a return statement with the "right" discrimiants or bounds is executed.
+  The only solution for this problem is not have the permission at all, but this is
+  too unusual of a case to worry about the effects of the permission, especially
+  given the implementation difficulties for build-in-place objects that this
+  permission is intended to ease.
+
+[This is my question from the previous mail, fleshed out a bit. Seems important
+to mention, as it is the counterpoint to the previous paragraph. There's probably
+a better way to say this.]
+
+  Note that the mutable-discriminant case only happens when
+  build-in-place initialization is optional. This means that any difficulties
+  associated with implementing build-in-place initialization without these
+  permissions can be sidestepped by not building-in-place.
+
+[From the original notes.]
+
+And then the examples in the current AI should be moved to the discussion (and
+probably lots of the discussion blown away).
 
 ****************************************************************

Questions? Ask the ACAA Technical Agent