CVS difference for 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).
@@ -50,40 +50,25 @@
- 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
+ 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
+ - 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
- 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
+ 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.
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
- The "intermediate constraint" wording refers to cases like
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:
type T (Is_Big : Boolean := True) is
@@ -186,7 +170,7 @@
function F return T is
- return X : T do
+ return X : T do -- X is unconstrained
X.Big_Component := (others => 'Y');
X := (Is_Big => False);
@@ -197,13 +181,12 @@
- 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.
@@ -471,6 +454,10 @@
+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.
@@ -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
+> - 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
+ return O : Rec(4) do -- (1)
+ if <some condition> then goto Different_Object; end if;
+ end return;
+ 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
+> 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.
+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
+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