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

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

--- ai05s/ai05-0066-1.txt	2007/10/23 03:22:55	1.1
+++ ai05s/ai05-0066-1.txt	2008/02/05 05:36:13	1.2
@@ -1,5 +1,6 @@
-!standard 3.10.2(10/2)                                        07-10-22    AI05-0066-1/01
-!standard 7.6.1(3/2)
+!standard 3.10.2(14.4/2)                                      08-02-03    AI05-0066-1/02
+!standard 7.6.1(13/2)
+!standard 7.6.1(13.1/2)
 !class binding interpretation 07-10-22
 !status work item 07-10-22
 !status received 07-09-13
@@ -65,10 +66,71 @@
-** TBD **
+Modify 3.10.2(14.4/2) as follows (this includes the wording change of AI05-0024-1):
+    In the first case, the allocated object is said to be a
+    coextension of the object whose discriminant designates it, as well
+    as of any object of which the discriminated object is itself a
+    coextension or subcomponent. All coextensions of an object are
+    finalized when the object is finalized (see 7.6.1){, except in the
+    case of an aggregate or function call that is used (in its entirety)
+    to directly initialize a part of an object}. {In this case, the
+    coextensions of the result of evaluating the aggregate or function
+    call become coextensions of the object being initialized and are not
+    finalized until the object being initialized is ultimately finalized.}
+Modify 7.6.1(13) as follows:    
+    The master of an object is the master enclosing its creation whose
+    accessibility level (see 3.10.2) is equal to that of the object,
+    except in the case of an anonymous object representing the result of
+    an aggregate or function call. The master of such an anonymous
+    object is the innermost master enclosing the evaluation of the
+    aggregate or function call, which may be the aggregate or function
+    call itself.   
+    In 3.10.2 we assign an accessibility level to the result of an
+    aggregate or function call that is used to directly initialize a
+    part of an object based on the object being initialized.  This is
+    important to ensure that any access discriminants denote objects
+    that live at least as long as the object being initialized. 
+    However, if the result of the aggregate or function call is not
+    built directly in the target object, but instead is built in an
+    anonymous object that is then assigned to the target, the anonymous
+    object needs to be finalized after the assignment rather than
+    persisting until the target object is finalized (but not its
+    coextensions). (Note than an implementation is never required to
+    create such an anonymous object, and in some cases is required to
+    *not* have such a separate object, but rather to build the result
+    directly in the target.)
+Modify 7.6.1(13.1/2) as follows:
+    In the case of an expression that is a master, finalization of any
+    (anonymous) objects occurs [as the final part of] {after completing}
+    evaluation of the expression {and use of the objects, prior to starting
+    the execution of any subsequent construct}.
+The definition of accessibility level for function results and
+aggregates given in the first sentence of 3.10.2(10/2) is relevant when
+the object might have an access discriminant, or when the the result
+might be built directly in the object being initialized. However, unless
+the type is limited, it is generally implementation-defined whether the
+result will be built directly in the target. On the other hand, when a
+separate anonymous object is created for a function or aggregate, we
+want that object to be finalized after use. We accomplish this by
+associating a shorter-lived master with any temporary object used to
+hold the value of the aggregate or function call, while still assigning
+it an accessibility level that will ensure the appropriate accessibility
+checks are performed and the appropriate accessibility level for any
 It has been suggested that this AI should be combined with AI05-0067-1. However, this AI
 deals with cases where the lifetime of the objects is required to be too long in the
 canonical semantics. The problem is worst for functions that are not build-in-place.
@@ -127,7 +189,7 @@
 allowing early finalizations of objects containing tasks could unpredictably stall the
 program waiting for task termination. Thus, tasks that are not waiting for termination
 need to be excluded from early finalization. An Implementation Permission like the
-following is recommended:
+following would be recommended:
    An implementation is permitted to finalize an object earlier
    than these rules would otherwise allow if the object is not accessible by any path
@@ -139,7 +201,7 @@
 (The part in square brackets is repeated from 7.6(11/2), and thus follows; we would need
 to explicit say something else if we don't want that.)
---!corrigendum 7.6(28)
+--!corrigendum 7.6.1(13)
 !ACATS Test
@@ -606,6 +668,16 @@
 semantics.  I think that describing the effect of build-in-place in
 high-level semantic terms would be much preferable to the current
 hand-waving in the IR.
+From: Tucker Taft
+Sent: Sunday, February 3, 2008 10:00 PM
+Here is an attempt at fixing the accessibility
+level rules for aggregates and function calls used
+to initialize an object.  It probably will need to
+be coordinated with AI05-67. [This is version /02 of the AI - ED]

Questions? Ask the ACAA Technical Agent