CVS difference for ais/ai-00147.txt

Differences between 1.8 and version 1.9
Log of other versions for file ais/ai-00147.txt

--- ais/ai-00147.txt	2000/12/06 21:46:43	1.8
+++ ais/ai-00147.txt	2002/02/07 04:56:41	1.9
@@ -1,4 +1,4 @@
-!standard 07.06    (21)                               99-07-27  AI95-00147/07
+!standard 07.06    (21)                               02-02-06  AI95-00147/08
 !class binding interpretation 96-06-06
 !status work item 99-04-20
 !status ARG Approved 6-0-2  99-03-26
@@ -23,17 +23,21 @@
 An implementation is permitted to omit implicit Initialize, Adjust and
 Finalize calls and associated assignment operations on an object of
 non-limited controlled type if
-  a) any usage of the value of the object after the implicit Initialize or
+  a) the implicit Initialize call does not affect the external effect of any
+      program execution, and
+  b) any usage of the value of the object after the implicit Initialize or
      Adjust call and before any subsequent Finalize call on the object
      does not affect the external effect of any program execution, and
-  b) after the omission of such calls and operations, any execution of
+  c) after the omission of such calls and operations, any execution of
      the program that executes an Initialize or Adjust call on an object
      or initializes an object by an aggregate will also later execute a
      Finalize call on the object and will always do so prior to assigning
-     a new value to the object.
-This permission applies even if the implicit calls have additional effects.
+     a new value to the object, and
+  d) the assignment operations associated with the omitted Adjust calls
+     are also omitted.
+This permission applies to Adjust and Finalize calls even if the
+implicit calls have additional external effects.
 
-
 The last sentence of 7.6(21) is amended to include the omission of the
 finalization of the anonymous object (along with the adjustment) and to
 exclude the optimization when there are any access values designating
@@ -54,7 +58,8 @@
      null;
   end;                  -- Finalize(X)
 
-Are the calls really needed for an obviously "dead" variable ?  [No]
+Are the calls really needed for an obviously "dead" variable ?  [No, unless
+Initialize is user-defined and has an external effect.]
 
 Second example:
 
@@ -70,7 +75,8 @@
 of a temporary anonymous object. Is it really necessary to mandate
 the execution of the first assignment and its implicit calls, merely for
 the sake of potential side-effects of these calls ? [No]
-Do we really have to Initialize and immediately thereafter Finalize X ? [No]
+Do we really have to Initialize and immediately thereafter Finalize X ? [No,
+unless Initialize is user-defined and has an external effect.]
 
 
 Third example:
@@ -125,40 +131,42 @@
 
 
 !recommendation
-
-For limited controlled types, the canonical semantics apply.
 
-For non-limited controlled types, matching pairs of Adjust/Finalize
-and Initialize/Finalize calls may be eliminated by the implementation as
-follows:
-
-For an explicit initialization of an object or an assignment to it,
-where the assigned value is not read after the Adjust call (if any)
-and prior to the Finalize call for the next assignment to the object
-or for its destruction, the Adjust/Finalize pair of calls (and the
-value assignment) need not be performed.
-
-For an implicit Initialize call, where the initialized value is not
-read after the Initialize call and prior to the Finalize call for the
-next assignment to the object or for its destruction, the
-Initialize/Finalize pair of calls need not be performed.
-
-An intermediate recipient object in the flow of a value from a
-source to its final destination, where the value of the intermediate
-object is not used thereafter, can be eliminated along with all
-operations on it by assigning the value directly from its source to
-the final destination and adjusting it.
-
-The last sentence of 7.6(21) omits an important additional constraint:
-In order for the adjustment to be omitted, it must also be guaranteed
-that there are no access values designating the anonymous object as a whole.
+(See Summary.)
 
 !wording
 
-7.6(18-21) need to be carefully rephrased to encompass the permissions
-stated in the !summary.
-
-The last sentence of 7.6(21) needs to be amended as stated in the !summary.
+Replace the last sentence of 7.6(21), which currently reads:
+"Even if an anonymous object is created, the implementation may move
+its value to the target object as part of the assignment without
+re-adjusting so long as the anonymous object has no aliased
+subcomponents."
+by
+"If an anonymous object is created, the implementation may move its value
+to the target object as part of the assignment without re-adjusting so
+long as the anonymous object has no aliased subcomponents and there are no
+access values designating the anonymous object as a whole. The anonymous
+object is then finalized."
+
+Add a new bulleted paragraph after 7.6(21):
+
+Furthermore, an implementation is permitted to omit implicit
+Initialize, Adjust and Finalize calls and associated assignment
+operations on an object of non-limited controlled type if
+  a) the implicit Initialize call does not affect the external effect of any
+      program execution, and
+  b) any usage of the value of the object after the implicit Initialize or
+     Adjust call and before any subsequent Finalize call on the object
+     does not affect the external effect of any program execution, and
+  c) after the omission of such calls and operations, any execution of
+     the program that executes an Initialize or Adjust call on an object
+     or initializes an object by an aggregate will also later execute a
+     Finalize call on the object and will always do so prior to assigning
+     a new value to the object, and
+  d) the assignment operations associated with omitted Adjust calls are
+     also omitted.
+This permission applies to Adjust and Finalize calls even if the
+implicit calls have additional external effects.
 
 !discussion
 
@@ -266,27 +274,20 @@
 interesting are Adjust/Finalize pairs for an initialized variable that
 is never used.
 
-Consider also, for example, if the user had written
-   "Result: Some_Controlled_Type;
-   ... Result := F;"
-above, instead of "Result: Some_Controlled_Type := F;".
-
-Canonical semantics would then cause a pair of Initialize/Finalize
-calls on Result, followed by an Adjust call, while the original
-program caused only the Adjust call.  A semantics that makes these two
-alternatives significantly different, is surely a surprise to many
-users. Permission to eliminate the Initialize/Finalize pair creates at
-least the possibility that the two alternatives might result in the same
-behavior (and acts as minor additional incentive to the programmer to
-make Initialize and Finalize an "inverse" pair to get identical
-semantics from both alternatives).
+However, since the canonical semantics make clear that there is a
+single Initialize call, users might rely on this understanding and
+expect any external effects of the Initialize call to occur regardless
+of whether the value of the object is subsequently used or not.
+Therefore, we limit the optimization to those cases, in which the
+absence of external effects is ensured, in particular, for the default
+implementation of Initialize that does nothing.
 
 The optimizations argued for are restricted to those cases where, at
-Ada source level, an initialization or assignment occurs, but the
-assigned value is never used, or a "copy propagation" eliminates an
-intermediate recipient object in the flow of a value from one source
-to its final destination, where the value of the intermediate object
-is not used thereafter.
+Ada source level, an initialization (without externally visible side-effects)
+or assignment occurs, but the assigned value is never used, or a "copy
+propagation" eliminates an intermediate recipient object in the flow of
+a value from one source to its final destination, where the value of the
+intermediate object is not used thereafter.
 
 While the above discussion is formulated in terms of pairs of calls
 for simplicity sake, the real situation is slightly more complicated,

Questions? Ask the ACAA Technical Agent