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

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

--- ai05s/ai05-0050-1.txt	2008/12/02 06:01:19	1.7
+++ ai05s/ai05-0050-1.txt	2009/05/22 00:04:33	1.8
@@ -7,7 +7,7 @@
 !priority Medium
 !difficulty Medium
 !qualifier Omission
-!subject Return permissions are not enough for build-in-place
+!subject Return permissions are not enough for built-in-place return objects
 
 !summary
 
@@ -29,9 +29,10 @@
 
 !question
 
-Should the implementation permissions of 6.5(24/2) be revised? The current permission
-both requires inefficient implementations in some cases and also allows an exception to
-be raised in cases where no exception would be raised without the permission.
+Should the implementation permissions of 6.5(24/2) be revised? The current
+permission both requires inefficient implementations in some cases and also
+allows an exception to be raised in cases where no exception would be raised
+without the permission.
 
 !recommendation
 
@@ -46,12 +47,12 @@
   constrained nominal subtype, Constraint_Error may be raised at the point
   of the call (after abandoning the execution of the function body) if,
   while elaborating the return_subtype_indication or evaluating the expression
-  of a return statement that applies to the function body, it is determined 
-  that the value of the result will violate the constraint of the subtype 
-  of this object. 
-  
-with  
-  
+  of a return statement that applies to the function body, it is determined
+  that the value of the result will violate the constraint of the subtype
+  of this object.
+
+with
+
   For a function call used to initialize a composite object with a constrained
   nominal subtype or used to initialize a return object that is built in place
   into such an object:
@@ -72,17 +73,17 @@
 
 AARM Reason:
 
-  Without such a permission, it would be very difficult to implement "built-in-place"
-  semantics. The intention is that the exception is raised at same point that it
-  would have been raised without the permission; it should not change handlers if the
-  implementation switches between return-by-copy and built-in-place. This means
-  that the exception is not handleable within the function, because in the
-  return-by-copy case, the constraint check to verify that the result satisfies the
-  constraints of the object being initialized happens after the function returns.
-  This implies further that upon detecting such a situation, the implementation
-  may need to simulate a goto to a point outside any local exception handlers prior
-  to raising the exception. 
-  
+  Without such a permission, it would be very difficult to implement
+  "built-in-place" semantics. The intention is that the exception is raised at
+  same point that it would have been raised without the permission; it should
+  not change handlers if the implementation switches between return-by-copy and
+  built-in-place. This means that the exception is not handleable within the
+  function, because in the return-by-copy case, the constraint check to verify
+  that the result satisfies the constraints of the object being initialized
+  happens after the function returns. This implies further that upon detecting
+  such a situation, the implementation may need to simulate a goto to a point
+  outside any local exception handlers prior to raising the exception.
+
 AARM Ramification:
 
   These permissions do not apply in the case of an extended
@@ -92,18 +93,18 @@
   We don't want this case raising an exception when the canonical semantics
   will not do so.
 
-  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 built-in-place objects that this
-  permission is intended to ease.
+  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 to 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 built-in-place objects that this permission is intended to ease.
 
   Note that the mutable-discriminant case only happens when
-  build-in-place initialization is optional. This means that any difficulties
+  built-in-place initialization is optional. This means that any difficulties
   associated with implementing built-in-place initialization without these
   permissions can be sidestepped by not building in place.
 
@@ -121,9 +122,9 @@
   expression of a return statement that applies to the function body, it
   is determined that the value of the result will violate the constraint
   of the subtype of this object.
-  
+
 This is a fine start, but more is needed in order to efficiently
-implement build-in-place initialization as required by AI95-00318-02.
+implement built-in-place initialization as required by AI95-00318-02.
 
 First, the original permission does not cover a function with a constrained
 result type. But such a function can be used to initialize an object
@@ -142,9 +143,9 @@
        -- requires initialization in place
 
     type Unconstrained is array (Positive range <>) of T;
-    
-    subtype S1 is Unconstrained (1 .. Ident_Int (20));
-    subtype S2 is Unconstrained (1 .. Ident_Int (10));
+
+    subtype S1 is Unconstrained (1 .. Some_Func_Returning_20);
+    subtype S2 is Unconstrained (1 .. Some_Func_Returning_10);
 
     function F return S1 is
     begin
@@ -161,10 +162,10 @@
 
 Thus the permission was extended to cover all types of function returns.
 
-Second, build-in-place is only required for limited types, so it would
-be ok for an implementation to ignore the implementation permissions of
+Second, built in place is only required for limited types, so it would
+be OK for an implementation to ignore the implementation permissions of
 6.5(24/2) for a nonlimited type. If an implementation chooses to implement
-build-in-place for nonlimited types, it must take care with types with
+built in place for nonlimited types, it must take care with types with
 mutable discriminants.
 
 In particular, it must not modify discriminants of constrained objects.
@@ -210,7 +211,7 @@
            when True  => Big_Component : String (1..1024) := (others => 'X');
          end case;
        end record;
-       
+
       function F return T is
       begin
         return X : T do -- X is unconstrained
@@ -218,20 +219,21 @@
          X := (Is_Big => False);
         end return;
       end F;
-      
+
       Small_Object : T (Is_Big => False) := F;
     begin
       null;
     end;
- 
+
 The permissive model would have allowed the declaration of X to raise
 Constraint_Error. But that is bad, as the function ultimately returns an
-object with the correct discriminant. As such, we did not use the
-permissive model.
+object with the correct discriminant. Moreover, this is a common way to
+declare objects where the constraint is not immediately known. As such,
+we did not use this permissive model.
 
 Finally, the implementation permissions of 6.5(24/2) should apply recursively in
-the case where a function call returns the result of another function call.
-For instance:
+the case where a function call returns the result of another function call. For
+instance:
 
   declare
     type T;
@@ -243,7 +245,7 @@
        -- requires initialization in place
 
     type Unconstrained is array (Positive range <>) of T;
-    
+
     function Some_Function return T is ... ;
 
     function F1 return Unconstrained is
@@ -261,8 +263,8 @@
 
     X : Unconstrained (1..3) := F2;
   begin null; end;
-  
-In the execution of this example, it should be ok for the return statement
+
+In the execution of this example, it should be OK for the return statement
 in F1 to raise Constraint_Error before executing any calls to Some_Function.
 
 ----
@@ -290,7 +292,7 @@
 refers to dynamic semantics, so there are no issues with privacy.
 
 ----
-  
+
 It is still possible for an implementation taking advantage of these permissions
 to raise Constraint_Error in cases were the canonical semantics would not have.
 That can happen when a return statement with the "wrong" discriminants is
@@ -317,29 +319,29 @@
 shape, the full function call which did not take advantage of the permission
 would not raise any exception.
 
-This cannot be avoided without dropping the permission completely; but that would
-have an unacceptable implementation cost for build-in-place objects. (Rec in the
-example above could be a type that requires build-in-place.)
+This cannot be avoided without dropping the permission completely; but that
+would have an unacceptable implementation cost for built-in-place objects. (Rec
+in the example above could be a type that must be built in place.)
 
 !corrigendum 6.5(24/2)
 
 @drepl
-If the result subtype of a function is unconstrained, and a call on the function is
-used to provide the initial value of an object with a constrained nominal subtype,
-Constraint_Error may be raised at the point of the call (after abandoning the
-execution of the function body) if, while elaborating the @fa<return_subtype_indication>
-or evaluating the @fa<expression> of a return statement that applies to the
-function body, it is determined that the value of the result will violate the
-constraint of the subtype of this object.
+If the result subtype of a function is unconstrained, and a call on the function
+is used to provide the initial value of an object with a constrained nominal
+subtype, Constraint_Error may be raised at the point of the call (after
+abandoning the execution of the function body) if, while elaborating the
+@fa<return_subtype_indication> or evaluating the @fa<expression> of a return
+statement that applies to the function body, it is determined that the value of
+the result will violate the constraint of the subtype of this object.
 @dby
 For a function call used to initialize a composite object with a constrained
 nominal subtype or used to initialize a return object that is built in place
 into such an object:
 
 @xbullet<If the result subtype of the function is constrained, and conversion of
-an object of this subtype to the subtype of the object being initialized
-would raise Constraint_Error, then Constraint_Error may be raised before
-calling the function.>
+an object of this subtype to the subtype of the object being initialized would
+raise Constraint_Error, then Constraint_Error may be raised before calling the
+function.>
 
 @xbullet<If the result subtype of the function is unconstrained, and a return
 statement is executed such that the return object is known to be
@@ -377,7 +379,7 @@
   expression of a return statement that applies to the function body, it
   is determined that the value of the result will violate the constraint
   of the subtype of this object.
-  
+
 This is a fine start, but more is needed in order to efficiently
 implement initialization in place as required by AI95-00318-02 .
 
@@ -402,7 +404,7 @@
        -- requires initialization in place
 
     type Unconstrained is array (Positive range <>) of T;
-    
+
     subtype S1 is Unconstrained (1 .. Ident_Int (10));
     subtype S2 is Unconstrained (1 .. Ident_Int (11));
 
@@ -471,7 +473,7 @@
 
   X1 : Rec (10) := F;
 
-For an in-out or out mode parameter with an unconstrained nominal subtype, 
+For an in-out or out mode parameter with an unconstrained nominal subtype,
 the formal inherits the constraints (if any) of the actual. The same
 model should apply, at the discretion of the implementation, to return objects
 in the case where the nominal subtype of the return object is unconstrained
@@ -507,7 +509,7 @@
        -- requires initialization in place
 
     type Unconstrained is array (Positive range <>) of T;
-    
+
     function Some_Function return T is ... ;
 
     function F1 return Unconstrained is
@@ -525,8 +527,8 @@
 
     X : Unconstrained (1..3) := F2;
   begin null; end;
-  
 
+
 In the execution of this example, it should be ok for the return statement
 in F1 to raise Constraint_Error before executing any calls to Some_Function.
 
@@ -563,7 +565,7 @@
 > structure, an implemention ought to be able to have a caller
 > simply pass in a buffer address; nothing more complicated than that should
 > be needed.
-> 
+>
 > In order to implement initialization in place, F must be passed the address of
 > X. An implementation must verify before the call that S1 and S2 have compatible
 > constraints - it would not do to pass in, for example, the address of a small
@@ -613,9 +615,9 @@
 
 > One could go further and handle cases involving qualified expressions
 > such as
-> 
+>
 >     Y : S1 := S2'(F);
-> 
+>
 > , but this doesn't seem necessary.
 
 I would think if we allow the optimization, then we
@@ -645,9 +647,9 @@
 nominal subtype.
 
 > -------
-> 
+>
 > Issue #3:
-> 
+>
 > The implementation permissions of 6.5(24/2) should apply recursively in
 > the case where a function call returns the result of another function call.
 
@@ -658,7 +660,7 @@
 > It seems that it would not make sense to propose RM wording for these issues
 > until we reach consensus on which, if any, of these issues require
 > any action at all.
-> 
+>
 > One could argue that no action is required for any them:
 >    #1 is essentially a complaint that the language requires an
 >       implementation to do something that is silly and complex, but
@@ -744,8 +746,8 @@
 > > buffer of the size the function expects, pass that buffer address into
 > > the function, finalize the returned value, and then raise Constraint_Error
 > > (or something like that).
-> 
-> Where does the language require this? 
+>
+> Where does the language require this?
 
 You're right, it really doesn't.
 
@@ -769,14 +771,14 @@
 We agree on the important point.
 
 > > Issue #2
-> 
+>
 > I think a nastier situation occurs when the default
 > value of the discriminant does *not* match that of the
 > target object, but the assignment produces a value
 > that *does* match.  For example:
-> 
+>
 >     X1 : Rec(5) := F;
-> 
+>
 > This is a case where if you do the optimization,
 > constraint_error is raised.  If you don't do the
 > optimization, then the function call succeeds
@@ -826,11 +828,11 @@
 ...
 >   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,
@@ -839,8 +841,8 @@
 
 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:
+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 ...
 
@@ -861,8 +863,9 @@
 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.
+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
@@ -870,13 +873,13 @@
 >   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.
+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
 
@@ -900,14 +903,15 @@
 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 
+>
+> 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:
+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.
@@ -924,19 +928,19 @@
 [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.
+  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.]
+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
@@ -955,11 +959,12 @@
 
 Here's a (belated) new version of AI-50. [This is version /04. - ED]
 
-I tried to obey the stuff in the minutes.  But I didn't define the term "dynamically
-matching".  I couldn't figure out any way to do so, other than the attempts recorded
-in the minutes, which apparently folks didn't like.  Anyway, it seems better to
-just state the rule, rather than defining yet more jaw-breaking terminology,
-especially since the term is used only for this one rule.
+I tried to obey the stuff in the minutes.  But I didn't define the term
+"dynamically matching".  I couldn't figure out any way to do so, other than the
+attempts recorded in the minutes, which apparently folks didn't like.  Anyway,
+it seems better to just state the rule, rather than defining yet more
+jaw-breaking terminology, especially since the term is used only for this one
+rule.
 
 I removed the stuff about Allocate and Deallocate, because that will be covered
 by AI-107, as I understand it.

Questions? Ask the ACAA Technical Agent