CVS difference for ais/ai-00147.txt

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

--- ais/ai-00147.txt	2002/03/12 01:38:49	1.10
+++ ais/ai-00147.txt	2002/03/13 00:48:26	1.11
@@ -1,5 +1,6 @@
-!standard 07.06    (21)                               02-02-25  AI95-00147/09
+!standard 07.06    (21)                               02-03-11  AI95-00147/10
 !class binding interpretation 96-06-06
+!status work item 02-03-11
 !status ARG Approved 7-0-0  02-02-12
 !status work item 99-04-20
 !status ARG Approved 6-0-2  99-03-26
@@ -35,8 +36,8 @@
      null;
   end;                  -- Finalize(X)
 
-Are the calls really needed for an obviously "dead" variable ?  [No, unless
-Initialize is user-defined.]
+Are the calls really needed for an obviously "dead" variable?  (No, unless
+Initialize is user-defined.)
 
 Second example:
 
@@ -51,9 +52,9 @@
 the Implementation Permission to omit creation, adjustment and finalization
 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,
-unless Initialize is user-defined.]
+the sake of potential side-effects of these calls? (No.)
+Do we really have to Initialize and immediately thereafter Finalize X? (No,
+unless Initialize is user-defined.)
 
 
 Third example:
@@ -68,12 +69,12 @@
   ...
 
 Should the declare block not be optimizable to
-  X1 := Init;   -- Finalize(X1); Adjust(X1)             [Yes]
+  X1 := Init;   -- Finalize(X1); Adjust(X1)             (Yes.)
 
 or the whole example to
-  X1: Controlled_Type := Init;  -- Adjust(X1);          [Yes]
+  X1: Controlled_Type := Init;  -- Adjust(X1);          (Yes.)
 
-avoiding so many unneeded calls ?
+avoiding so many unneeded calls?
 
 
 Finally, a more complicated example:
@@ -93,7 +94,7 @@
     X: Some_Controlled_Type := G;  -- Adjust
 
 Is an implementation allowed to optimize the above by creating the
-aggregate directly in X, thus avoiding all calls to Adjust and Finalize? [Yes]
+aggregate directly in X, thus avoiding all calls to Adjust and Finalize? (Yes.)
 (Such an optimization might well be feasible if F and G are inlined, or
 if the compiler is doing other kinds of inter-procedural analysis.  It
 might even be feasible without inter-procedural analysis, if the sizes of
@@ -102,9 +103,9 @@
 
 Note: Some of these issues came up during a discussion of ACVC test C760007.
 
-Finally, what is the meaning of the last sentence of 7.6(21) ? It seems to
+Finally, what is the meaning of the last sentence of 7.6(21)? It seems to
 allow elimination of an Adjust operation without eliminating a matching
-Finalize operation. Is this intended ? [No]
+Finalize operation. Is this intended? (No.)
 
 
 !recommendation
@@ -113,17 +114,11 @@
 
 !wording
 
-Replace the last sentence of 7.6(21), which currently reads:
+Delete the last sentence of 7.6(21), which 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 not finalized if this permission is used."
 
 Add a new bulleted paragraph after 7.6(21):
 
@@ -292,16 +287,30 @@
 optimization by its externally visible effects.
 
 Finally, the !question raises an issue with the last sentence of
-7.6(21), which indeed is seriously incomplete.  The sentence needs to
+7.6(21), which indeed is seriously incomplete. The sentence needs to
 be interpreted to mean that, along with the omission of the
-re-adjustment, the temporary object is not finalized either. Also,
-this permission causes a major problem in the case where the object
-itself is referenced by one of its subcomponents or by other objects
-reachable via subcomponents and properly modified by the Adjust call
-to refer to the object in question (e.g., as a means to track all
-objects of a certain type).  The sentence therefore needs to be
-amended to exclude the optimization in this case.
+re-adjustment, the temporary object is not finalized either.
 
+But that is not the only problem with this permission. It causes a major
+problem in the case where the object itself is referenced by one of its
+subcomponents or by other objects reachable via subcomponents and properly
+modified by the Adjust call to refer to the object in question (e.g., as a
+means to track all objects of a certain type).
+
+One way to solve this would be to amend the sentence to exclude the
+optimization in this case. However, to use the permission after such an
+amendment requires the compiler to examine the body of Adjust (and any
+subprograms that it calls) to insure that it does not create a reference to the
+object as a whole (such as the use of 'Access or 'Unchecked_Access). But the
+point of these permissions is to give cases where optimizations are allowed
+without looking at the implementation of Adjust or Finalize. Moreover, if the
+compiler does look into the body of Adjust, it can simply do an "as-if"
+optimization, where the Adjust and Finalize calls are removed as if the
+temporary object was never created (since the compiler can determine that there
+is no dependence on the location of the object), based on one of the other
+permissions in 7.6(21). Therefore, the permission adds nothing but words to the
+language, and the entire last sentence of 7.6(21) should be deleted.
+
 !ACATS test
 
 This ruling gives permissions for optimizations. Such permissions aren't
@@ -1982,6 +1991,116 @@
 
 Let me add to the discussion that I would prefer to see the entire sentence
 gone. (I never was convinced that this was a meaningful permission anyway.)
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Monday, March 11, 2002  8:05 PM
+
+Given Erhard's sentiments, everyone else's silence, and the fact that Pascal
+has decreed that this AI be turned back into a work item in any case, I've
+gone ahead and rewritten the AI to outright delete the last sentence of
+7.6(21) and to amend the discussion of the AI to say why.
+
+The sentence in question is:
+
+"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."
+
+My updated discussion says:
+
+Finally, the !question raises an issue with the last sentence of 7.6(21),
+which indeed is seriously incomplete. The sentence needs to be interpreted
+to mean that, along with the omission of the re-adjustment, the temporary
+object is not finalized either.
+
+But that is not the only problem with this permission. It causes a major
+problem in the case where the object itself is referenced by one of its
+subcomponents or by other objects reachable via subcomponents and properly
+modified by the Adjust call to refer to the object in question (e.g., as a
+means to track all objects of a certain type).
+
+One way to solve this would be to amend the sentence to exclude the
+optimization in this case. However, to use the permission after such an
+amendment that case requires the compiler to examine the body of Adjust (and
+any subprograms that it calls) to insure that it does not create a reference
+to the object as a whole (such as the use of 'Access or 'Unchecked_Access).
+But the point of these permissions is to give cases where optimizations are
+allowed without looking at the implementation of Adjust or Finalize.
+Moreover, if the compiler does look into the body of Adjust, it can simply
+do an "as-if" optimization, where the Adjust and Finalize calls are removed
+as if the temporary object was never created (since the compiler can
+determine that there is no dependence on the location of the object), based
+on one of the other permissions in 7.6(21). Therefore, the permission adds
+nothing but words to the language, and the entire last sentence of 7.6(21)
+should be deleted.
+
+Comments are welcome as always. (I've also made a bunch of editorial
+corrections, so that the AI style police won't need to be so busy...)
+
+****************************************************************
+
+From: Erhard Ploedereder
+Sent: Tuesday, March 12, 2002   8:15 AM
+
+I agree with Randy's rewording and the rationale for it.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Tuesday, March 12, 2002   3:07 PM
+
+Getting rid of the sentence does seem reasonable.  However, I still am
+interested in what we can say about allowing an object to be moved between
+Initialize/Adjust and Finalize.
+
+Any comments?
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Tuesday, March 12, 2002   3:42 PM
+
+At the risk of sounding like a broken record, I don't think there is
+anything (useful) that we can say.
+
+Such a movement can occur only if the compiler can prove that there are no
+accesses into any part (in a technical sense) of the object, or if the
+compiler can somehow "fix" any such accesses to point at the moved object.
+But in either case, these are optimizations already allowed by the language
+rules (of course, because there would be no change in the observable
+semantics), so there isn't anything useful (or necessary) to say.
+
+Any rule which went beyond that and allowed observable movement would break
+the "no visible access" OOP model which I believe is such an important
+advance of Ada 95. (After all, you don't need garbage collection for objects
+if you never heap allocate them.) And in particular, it would irretrievably
+break Claw (which keeps lists of windows for various purposes).
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Tuesday, March 12, 2002   4:44 PM
+
+The issue is that if the Finalize somehow checks whether the address
+is the same as it was at the point of Initialize, then it might
+be surprised.  I suppose the right answer is that 'Address is allowed
+to return different values for the same object during its lifetime.
+
+I'm not sure whether the RM says anything that contradicts this at
+the moment.  I suppose that in the Alsys Ada 83 compiler, objects
+with mutable discriminants could effectively move if they needed to
+be reallocated due to growing beyond their original allocated space.
+
+On the other hand, if there are long-lived values created using
+'Access at Initialize, then clearly those values must be updated if the
+object is moved and they are used after the move.
+
+So I suppose I have answered my own question.  If 'Address is allowed
+to return different values during the lifetime of an object, then moving
+an object is allowed, even if it is controlled, presuming 'Access still
+works "properly."
 
 ****************************************************************
 

Questions? Ask the ACAA Technical Agent