CVS difference for ais/ai-00147.txt

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

--- ais/ai-00147.txt	1999/04/01 19:46:17	1.5
+++ ais/ai-00147.txt	1999/04/20 19:45:55	1.6
@@ -691,3 +691,781 @@
 -Tuck
 
 ****************************************************************
+
+From: 	Tucker Taft
+Sent: 	Friday, April 16, 1999 3:14 PM
+
+Tom Moran wrote:
+>
+> I found AI-00147, which as far as I can see gives no significant
+> arguments *for* eliminating in the non-limited case, except "doing
+> Initialization/Finalization is expensive".  It seems to that either
+> the programmer intended the object to be declared, even though he
+> doesn't use it, or it was a mistake on his part and a warning should
+> be generated (as for unused Integer, Boolean, and other non-controlled
+> types).  So possibly such a warning in the non-limited case would be
+> reasonable, but simply assuming the programmer did not really intend
+> to declare the controlled object, is hubris.
+>   Or is there another AI that I missed?
+
+Here is a motivating example:
+
+    X : My_Controlled_Type;
+  begin
+    ...
+    X := Y;
+    ...
+  end;
+
+Presuming My_Controlled_Type has a user-defined Initialize,
+Finalize, and Adjust, the sequence of implicit calls currently
+required is:
+    Initialize(X);
+     ...
+    Finalize(X)
+    <copy Y to X>
+    Adjust(X)
+    ...
+    Finalize(X)
+
+The goal is to eliminate the first Initialize/Finalize pair.
+Doing this requires some care, because if an exception is raised
+before the assignment of Y to X, you don't want X to be finalized
+if it has never been initialized.
+
+Perhaps one way to resolve the concern is to give the permission
+to remove an Initialize/Finalize pair only if there is an assignment
+(presumably with Adjust) to the object, essentially allowing
+the creation of the object to be deferred until the first assignment,
+thereby bypassing the need for any default initialization.
+
+-Tuck
+
+****************************************************************
+
+From: 	Robert Dewar
+Sent: 	Saturday, April 17, 1999 8:33 AM
+
+My view is that this kind of optimization is unacceptable unless someone
+shows a REAL program where it makes a REAL difference.
+
+It is one thing to let optimizations affect exceptions, quite another to
+let them introduce non-deterministic semantics.
+
+I think this decision is a bad one, and it seems from the CLA discussion
+that I am not alone ...
+
+****************************************************************
+
+From: 	Robert A Duff
+Sent: 	Saturday, April 17, 1999 8:34 AM
+
+Tucker wrote:
+
+> Here is a motivating example:
+>...
+
+Another example: a function declares a local variable, does some stuff,
+returns the local, and the caller uses the function result to initialize
+an object (in an object declaration, say).  There's a lot of shuffling
+of data going on, and it would be nice to let the compiler eliminate
+some or all of it.  Eg, the compiler can often arrange for the local
+inside the function to occupy the same storage as the new object, thus
+avoiding lots of copying.  One can imagine a whole chain of function
+calls like this.  It would be a shame to disable that sort of
+optimization for controlled things.
+
+Nondeterministic semantics makes *me* uneasy, too, but in this case it
+seems worth it.
+
+- Bob
+
+****************************************************************
+
+From: 	Pascal Leroy
+Sent: 	Monday, April 19, 1999 5:19 AM
+
+> My view is that this kind of optimization is unacceptable unless someone
+> shows a REAL program where it makes a REAL difference.
+
+I think that the argument goes both ways: it doesn't seem very good to prevent
+this kind optimization unless someone shows a REAL program where it makes a
+REAL difference.
+
+I have not followed the CLA discussion, but if someone came up with real-life
+examples where the optimization (of its absence) made a difference, it would
+be interesting to know.  Everybody can come up with 20-line examples to make a
+point (and the ARG has done a lot of that on this AI) but the evidence is
+inconclusive unless it's real code from a real project.
+
+I must say that I am equally uncomfortable with the notion of making the
+dynamic semantics non-deterministic and with the notion of insisting on a
+pedantic and costly canonical model.
+
+Pascal
+
+****************************************************************
+
+From: 	Robert A Duff
+Sent: 	Monday, April 19, 1999 7:40 AM
+
+> I must say that I am equally uncomfortable with the notion of making the
+> dynamic semantics non-deterministic and with the notion of insisting on a
+> pedantic and costly canonical model.
+
+FWIW, making the semantics deterministic is a bigger change to the
+language.
+
+- Bob
+
+****************************************************************
+
+From: 	Robert Dewar
+Sent: 	Monday, April 19, 1999 9:08 AM
+
+<<I think that the argument goes both ways: it doesn't seem very good to prevent
+this kind optimization unless someone shows a REAL program where it makes a
+REAL difference.
+>>
+
+First, we definitely have some customer code which uses controlled types
+of this kind to achieve local finalization. Yes, they could be limited,
+but the RM does not require this, and this is a change they would have
+to make now.
+
+Second, optimizations are supposed to be improvements in your code that
+are *TRANSPARENT* to the semantic behavior.
+
+I think it is a VERY bad precedent to allow an optimization that has
+a fundamental effect on the semantics of the program, NOT related to
+raising of built-in exceptions.
+
+THis is not just an interpretation, it is a significant change in the
+language, and for that we need a significant justification.
+
+The justification that says "this change in the language may allow some
+programs to run faster, but we have no data to support this claim" is
+FAR too weak to justify an incompatible language change that *WILL*
+cause trouble for existing programs.
+
+You say we should not prevent an optimization. BUT THIS IS NOT AN
+OPTIMIZATION. I don't have any quarrel with the optimization, My
+quarrel is with the fact that this is a language change!
+
+In GNAT, we have introduced a pragma
+
+pragma Finalize_Storage_Only (controlled type);
+
+which tells the compiler that the finalization routine is present ONLY
+for storage reclamation purposes (i.e. that it has no semantics, and can
+therefore be omitted on an optimization basis, e.g. at the outer level, or
+in our Java implementation all the time).
+
+I think the proper approach here is to use this or a similar pragma to give
+the compiler permission to make the "optimization".
+
+Using other languages, many programmers are quite familiar with the idea
+that optimization changes the behavior of the program. They don't like it,
+and often they decide they cannot risk doing ANY optimization.
+
+In Ada, we have tried to be very careful to reassure people that, except
+for the case of built-in language checks, something that people do not
+care too much about when talking about high performance, since most often
+such checks are suppressed, OPTIMIZATION in Ada IS OPTIMIZATION.
+
+It does NOT change the semantics.
+
+This proposed decision by the ARG is a major step backwards. The only
+possible justification would be if we knew it had a major performance
+significance, but we don't know that.
+
+I run across cases all the time where an optimization would be attractive
+but is prevented by the Ada semantics. My reaction is to forget the
+optimization, not go changing the language to permit implementation
+dependent semantics!
+
+Robert
+
+****************************************************************
+
+From: 	Tucker Taft
+Sent: 	Monday, April 19, 1999 10:02 AM
+
+But Robert, we already have a number of permissions relating
+to removing controlled intermediaries...
+
+In any case, I am getting more enamored of an intermediate position,
+which restricts the permission to apply only to types for
+which there is no user-defined Initialize procedure.  Without
+a user-defined Initialize procedure, there is no real guarantee
+of atomicity relative to abort anyway, since component default
+initializations can occur pretty much in any order.  Also, all
+the examples which seem to cause problems involve types with
+user-defined Initialize procedures, be they limited or non-limited.
+In general, programmers should (already?) be aware that defining their own
+Initialize procedure increases the overhead associated with
+controlled types, while it provides more atomicity guarantees.
+
+-Tuck
+
+****************************************************************
+
+From: 	Robert Dewar
+Sent: 	Monday, April 19, 1999 10:35 AM
+
+I like this better, note that nearly 100% of the time, such cases will
+correspond to the Finalize_Storage_Only case anyway, where it is entirely
+reasonable to optimize.
+
+****************************************************************
+
+From: 	Gary Dismukes
+Sent: 	Monday, April 19, 1999 12:13 PM
+
+I think I can get behind this proposed revision. :-)
+
+This sounds like a reasonable compromise and addresses my
+concerns about affecting existing code and surprising users.
+
+Time for another round of revision on the AI...
+
+****************************************************************
+
+From: 	Robert A Duff
+Sent: 	Monday, April 19, 1999 12:04 PM
+
+> I think it is a VERY bad precedent to allow an optimization that has
+> a fundamental effect on the semantics of the program, NOT related to
+> raising of built-in exceptions.
+
+I prefer to say "change the behavior" rather than "change the semantics"
+-- semantics being the whole set of possible behaviors a program might
+have, so optimizations can't change semantics by definition.
+
+Yes, the rules we're talking about allow an optimization to change the
+behavior of a program (compared to without optimization, or compared to
+some other optimizer, or whatever).  But there are lots of other places
+in Ada that have the same property (in addition to 11.6, which you say
+doesn't count).  For example, order of evaluation of actual parameters.
+(I would have preferred a strict left-to-right order, for the same
+reasons you're worried about this controlled-types stuff.  Presumably
+the decision was made to allow arbitrary order because somebody thought
+it would increase efficiency, and people find side effects distasteful
+anyway, so the order shouldn't really matter too much.  Note that the
+controlled types issue is similar -- the optimization mainly affects
+programs that have "evil" side effects.)  Another example is
+pass-by-copy vs pass-by-reference.  Thankfully, Ada has fewer such cases
+than some other languages.
+
+I usually argue against non-determinism.  But in this case, it seems
+worthwhile -- I hardly think it's precedent-setting.
+
+> Can you elucidate this comment ...
+>
+>> Making the semantics deterministic is a bigger change to the
+>> language.
+>>
+
+I just meant that the RM clearly allows *some* of the behavior-changing
+optimizations related to eliminating Finalize and friends.  So
+forbidding any such optimizations for controlled types seems like a
+radical change to the language; a change in philosophy, whereas merely
+changing (and/or clarifying) exactly which such optimizations we're
+going to allow seems like a minor tweak to the language (albeit not
+necessarily an upward compatible one).
+
+I guess I'm pretty ambivalent on this issue.  I could certainly live
+with either the AI as currently written up, or with Tucker's latest
+compromise solution.  I could even live with forbidding all such
+optimizations, but as I said, that seems like a bigger language change
+to me.
+
+- Bob
+
+****************************************************************
+
+From: 	Randy Brukardt
+Sent: 	Monday, April 19, 1999 1:52 PM
+
+I assume this discussion is about AI-0147. Not all of the mail makes this
+clear, perhaps some of participants need to go back and re-read the AI...
+
+What I find most important is that a decision is made on this AI, so it can
+be enforced. If we don't get this done, users will not have any recourse if
+compilers implement the rules as written in the RM. (This has caused
+problems in the past.)
+
+In any case, I don't understand Tucker's "intermediate position". I don't
+know exactly what permission he is talking about, and I suspect that Tucker
+and Robert are interpreting his position differently.
+
+I can think of three possible interpretations of Tucker's "intermediate
+position":
+
+1) He means all of the permissions of this AI. That would mean that the
+assignment of a type with a user-defined initialize routine gets the
+canonical semantics - which means two Adjusts and two Finalizes.
+
+I certainly hope this isn't what Tucker meant. Such a change would make
+most compilers need to change, and would make Claw quite a bit slower
+(since most Claw controlled types have user-defined initialize routines,
+and some are assigned often). How significant this would be, I don't know,
+but I don't believe this is what Tuck meant (although it might have been
+what Robert thought Tuck meant.)
+
+2) He means just the permission to remove Initialize calls, and he meant
+what he said: user-defined Initialize calls cannot be removed.
+
+Such a position is exactly the same as saying that Initialize calls can't
+be removed - as the predefined Initialize does nothing. I don't see how
+this can be an "intermediate" position - it seems to be a complex way of
+saying one of the endpoint positions. Therefore, I think that Tucker must
+have had something else in mind.
+
+3) He means just the permission to remove Initialize calls, and he meant
+that top-level user-defined Initialize calls cannot be removed, but
+user-defined initialize calls in components can be removed.
+
+I find this idea to be silly. This just makes a more complicated
+permission, with no corresponding benefit. If the user wraps the controlled
+(lock) object in a record, suddenly the Initialize call can be removed.
+
+
+The primary argument for allowing the removal of Initialize is that the
+permission to remove operations in the other, similar cases already exists.
+If Control is a Controlled type:
+
+     declare
+          X : Control; -- Can we remove the object, Initialize, and
+Finalize?
+          Y : Control := (aggregate); -- We can remove the object and the
+Finalize.
+          Z : Control := X; -- We can remove the object, Adjust, and
+Finalize.
+     begin
+          null;
+     end;
+
+Why should X be treated differently than Y and Z?
+
+Note that a non-limited Lock type is a very dubious construct. (Even if
+Robert's customers have already written it). Assignments of the lock would
+have to have clearly defined semantics (probably to clone the lock), and
+would make it easy to hold the lock forever (get copy it into something
+that never goes away).
+Another possible semantics is for assignment to NOT copy the lock, but then
+of course assignment is a vacuous operation, and it would have been better
+for the user to have declared the type limited to avoid the operation in
+the first place.
+
+I suspect that most, if not all, people who have such locks have never
+thought about the implications of making the item non-limited, especially
+what it means to assign it.
+
+In any case, this is an implementation permission, and Robert is free to
+ignore it. Then GNAT wouldn't break the user's code, even if it not
+guaranteed to work on other compilers. RRS is likely to ignore most such
+permissions, because they confuse users more than they save. But it is
+clear we need a permission to eliminate "extra" operations on assignments,
+and how far that is taken is only a matter of degree.
+
+Therefore, I would prefer to leave the AI alone, as it most consistent the
+way it currently is. My second choice is to placate people by simply saying
+that Initialize calls are never "optimized" away; but of course that
+doesn't apply to Adjust or Finalize calls. More restrictive rules are more
+likely to make Ada code perform poorly when compared to other languages,
+and don't buy us much.
+
+                                        Randy.
+
+****************************************************************
+
+From: 	Tucker Taft
+Sent: 	Monday, April 19, 1999 6:00 PM
+
+> I can think of three possible interpretations of Tucker's "intermediate
+> position":
+> 
+> 1) He means all of the permissions of this AI. That would mean that the
+> assignment of a type with a user-defined initialize routine gets the
+> canonical semantics - which means two Adjusts and two Finalizes.
+> 
+> I certainly hope this isn't what Tucker meant. 
+
+It isn't.
+
+> 2) He means just the permission to remove Initialize calls, and he meant
+> what he said: user-defined Initialize calls cannot be removed.
+> 
+> Such a position is exactly the same as saying that Initialize calls can't
+> be removed - as the predefined Initialize does nothing. I don't see how
+> this can be an "intermediate" position - it seems to be a complex way of
+> saying one of the endpoint positions. Therefore, I think that Tucker must
+> have had something else in mind.
+
+This is in fact what I had in mind.  It is apparently more acceptable
+to Robert and Gary, and it does, I believe, resolve most of the
+complaints.  You are right that I could have expressed the
+final rule more simply, but I was trying to relate it to
+the existing proposal.  It means effectively that user-defined Initialize
+calls cannot be optimized away (unless the compiler "looks inside" them
+somehow).  In my experience, user-defined Initialize procedures are 
+relatively rare for non-limited controlled types.  (Your experience
+may of course differ.)  They are needed only if there is some
+kind of default initialization that needs protection against
+abort, which seems to be exactly the kind of thing which might be bad
+news to remove.  There are a number of simplifications possible for
+controlled types with no user-defined Initialize routines, so users
+who are concerned about performance would presumably avoid creating
+"trivial" Initialize routines, and only create one when they really
+have something "important" to do, abort-deferred.
+
+> 3) He means just the permission to remove Initialize calls, and he meant
+> that top-level user-defined Initialize calls cannot be removed, but
+> user-defined initialize calls in components can be removed.
+
+Nope, I didn't mean that.
+
+Basically I was convinced by the well-founded claim that many Ada 
+programmers avoid "limitedness" like the plague.  However, to use
+a controlled type to do something like seize a lock, you pretty
+much have to have a user-defined Initialize routine, so that seems
+like a safer way to identify a "hands-off" situation than requiring
+all "hands off" controlled types to be limited.
+
+
+>                                         Randy.
+
+-Tuck
+
+****************************************************************
+
+From: 	Robert Dewar
+Sent: 	Monday, April 19, 1999 6:21 PM
+
+<<Basically I was convinced by the well-founded claim that many Ada
+programmers avoid "limitedness" like the plague.  However, to use
+a controlled type to do something like seize a lock, you pretty
+much have to have a user-defined Initialize routine, so that seems
+like a safer way to identify a "hands-off" situation than requiring
+all "hands off" controlled types to be limited.
+>>
+
+Right, that is EXACTLY my feeling, and is why I agree with this proposal.
+
+****************************************************************
+
+From: 	Randy Brukardt
+Sent: 	Monday, April 19, 1999 7:45 PM
+
+>> 2) He means just the permission to remove Initialize calls, and he meant
+>> what he said: user-defined Initialize calls cannot be removed.
+>>
+>> Such a position is exactly the same as saying that Initialize calls
+can't
+>> be removed - as the predefined Initialize does nothing. I don't see how
+>> this can be an "intermediate" position - it seems to be a complex way of
+>> saying one of the endpoint positions. Therefore, I think that Tucker
+must
+>> have had something else in mind.
+
+>This is in fact what I had in mind.  It is apparently more acceptable
+>to Robert and Gary, and it does, I believe, resolve most of the
+>complaints.  You are right that I could have expressed the
+>final rule more simply, but I was trying to relate it to
+>the existing proposal.  It means effectively that user-defined Initialize
+>calls cannot be optimized away (unless the compiler "looks inside" them
+>somehow).
+
+OK, but I don't think this is new - it just the original proposal that was
+defeated at the Paris meeting and again in Erhard's E-Mail vote.
+
+>In my experience, user-defined Initialize procedures are
+>relatively rare for non-limited controlled types.  (Your experience
+>may of course differ.)  They are needed only if there is some
+>kind of default initialization that needs protection against
+>abort, which seems to be exactly the kind of thing which might be bad
+>news to remove.
+
+Not exactly. If the initialization needs control structures (i.e. IF), it
+is much more convinient to write that as an Initialize routine rather than
+as a series of functions. If the initialization requires interaction
+between multiple components, it also might need to be a routine. (Note that
+the second hasn't happened to Claw).
+Claw uses the Initialize routine to set up the clone pointers (which point
+to self at initialization); I don't recall if this is legal in
+initialization expressions for a non-limited type.
+
+>There are a number of simplifications possible for
+>controlled types with no user-defined Initialize routines, so users
+>who are concerned about performance would presumably avoid creating
+>"trivial" Initialize routines, and only create one when they really
+>have something "important" to do, abort-deferred.
+
+I suppose this is not much different than requiring users to look at making
+locks limited, but it might force significant redesigns.
+
+>Basically I was convinced by the well-founded claim that many Ada
+>programmers avoid "limitedness" like the plague.
+
+They need some re-education. :)
+
+>However, to use
+>a controlled type to do something like seize a lock, you pretty
+>much have to have a user-defined Initialize routine, so that seems
+>like a safer way to identify a "hands-off" situation than requiring
+>all "hands off" controlled types to be limited.
+
+Certainly, I would rather that the AI be reverted to this form (this was
+the way it was written before the Paris meeting, I believe), than that it
+not get approved at all. I've personally never cared that much about this
+issue - my main concern is that bogus optimizations allowed by the RM get
+deep-sixed, the sooner the better. Therefore, I would switch my vote here
+if it would help get the this AI done. I fear, however, that procedurally
+we will put off the completion of the AI another year, and it certainly
+will miss the Corrigendum (meaning that the test suite won't be able to
+enforce the ruling for a long while).
+
+                                Randy.
+
+****************************************************************
+
+From: 	Gary Dismukes
+Sent: 	Monday, April 19, 1999 11:43 PM
+
+> Certainly, I would rather that the AI be reverted to this form (this was
+> the way it was written before the Paris meeting, I believe), than that it
+> not get approved at all. I've personally never cared that much about this
+> issue - my main concern is that bogus optimizations allowed by the RM get
+> deep-sixed, the sooner the better. Therefore, I would switch my vote here
+> if it would help get the this AI done. I fear, however, that procedurally
+> we will put off the completion of the AI another year, and it certainly
+> will miss the Corrigendum (meaning that the test suite won't be able to
+> enforce the ruling for a long while).
+
+While I agree it would be nice to have this included in the Corrigendum
+(though hardly earth-shattering if it isn't), I'm not sure why you're so
+concerned about "enforcing the ruling".  It seems that the only thing
+you can reasonably test is that Initialize doesn't get optimized away,
+assuming that we go with the "new" revised rules (that should be tested
+I suppose, but I'm not too worried that compilers are going to violate
+it if that's what we decide).  If we stick with the current write-up
+for AI-147, then what are you going to "enforce", that compilers don't
+do too much optimization?  That doesn't seem worth expending the effort
+to test, even if feasible.
+
+****************************************************************
+
+From: 	Erhard Ploedereder
+Sent: 	Tuesday, April 20, 1999 4:24 AM
+
+> What I find most important is that a decision is made on this AI, so it can
+> be enforced. If we don't get this done, users will not have any recourse if
+
+No way.  This being a permission, there is no test to enforce it. In fact,
+some of the discussion reads as if this were seen as a requirement, which it
+surely isn't. Nor does GNAT have to implement it, if the GNAT-suppliers so
+decide. The ACATs impact is that some existing tests may need to be modified
+to allow for the permission. This is equally true, if the AI is scaled back
+to Adjust/Finalize (again) or recast as Adjust/user-defined Initialize/Finalize.
+
+On the discussion per se:
+It is somewhat illuminating to try to write examples with non-limited types
+and unreferenced lock variables to implement locking semantics and then do the
+experiment: "What if, in the course of maintenance, somebody decides to
+assign a value that includes a lock." Try to write the "Adjust" such that the lock
+protection remains (presuming for the moment that the maintainer is aware
+of the lock at all; if he isn't, he's in deep trouble to begin with, as the
+lock will go away silently with the first finalization that now happens on either
+copy.) You will find yourself in deeeeeeep trouble (at least I do) trying to
+write the Adjust, because of the indeterminate number of Adjust calls.
+
+Somewhat pointedly, one can then ask the question: "Do I prefer to be caught
+by an optimization destroying my envisaged lock protection and would I
+rather be screwed during maintenance ?" Put differently: "When do I learn to
+make things limited when they need to be limited ? Sooner or later, I will.
+All else is pretty risky." But then, programmers like to live in the fast
+lane, don't they :-) Let's save the "limited" keystrokes and (let somebody
+else) live dangerously.
+
+Erhard
+
+****************************************************************
+
+From: 	Robert Dewar
+Sent: 	Tuesday, April 20, 1999 9:04 AM
+
+Well if you want to worry about this (I think it is a marginal case), then
+just write an Adjust that raises Program_Error! THat should help the
+incompetent maintenance programmer :-)
+
+Remember that one reason for not making it limited is that it means you
+can initialize it with just an initialization expression, and I have
+seen this done!
+
+Let me say one thing about Erhard's point about maintenance. I would
+accept this argument *during* the design, but not after the standard
+is issued!
+
+The point here is that we have working portable programs, written according
+to the rules in the RM. And the ARG has just made a ruling that these
+programs are no longer portable, but rather implementation dependent.
+
+This means that the programs MAY but not necesarily WILL stop working
+suddenly.
+
+That is the worst kind of disruption that the ARG can cause. They had
+better have a very good reason for it.
+
+Let's ask the reason for creating this incompatible chaos
+
+"Well we think it might speed up some programs?"
+
+"How significant is this speed up"
+
+"We haven't any idea, we never measured it"
+
+Pretty weak ground if you ask me!
+
+****************************************************************
+
+From: 	Erhard Ploedereder
+Sent: 	Tuesday, April 20, 1999 10:07 AM
+
+> Remember that one reason for not making it limited is that it means you
+> can initialize it with just an initialization expression, and I have
+> seen this done!
+
+That's the first technical argument that I have seen that really holds
+water. We got the programmers between a rock and a hard place with this
+prohibition of initialization for limited types. (Where did that one come
+from, anyway ? Surely, an aggregate could be allowed, especially in view
+of the "must build in place"-AI, but that's a different story.)
+
+However, when you read AI-147, it does not extend its permission to
+this case, i.e., in this case the explicit initialization and the
+finalization will happen.
+
+..unless the initialization is provably side-effect free, in which case the
+general observability argument might be envoked (see below). But that won't
+be the case for the locking example.
+
+Relatedly, a question on Tuck's compromise: Does that include elimination of
+a corresponding call on user-defined Finalize, if the Initialize is
+defaulted ?
+
+Erhard
+
+****************************************************************
+
+From: 	Tucker Taft
+Sent: 	Tuesday, April 20, 1999 11:26 AM
+
+Erhard Ploedereder wrote:
+> ...
+> Relatedly, a question on Tuck's compromise: Does that include elimination of
+> a corresponding call on user-defined Finalize, if the Initialize is
+> defaulted ?
+
+Yes, the point of the permission is to allow removal of the
+Finalize without having to "look inside" it.  We would not be
+permitting the removal of user-defined Initialize.
+
+Randy should speak for himself, but I suspect his interest in this
+AI is that it talks about other issues where he wants to create
+tests to be sure that compilers are not overstepping their bounds
+in optimizing away stuff.  He just wants this Initialize/Finalize
+part to be resolved, so he can write tests for the other parts,
+where he has already been burned by over-aggressive compilers.
+
+As far as your general point about initializing limited types,
+I agree that we could get creative here some day.  What would
+make sense to me is if you could initialize from an aggregate
+or a function call, but not by copying an existing limited object.
+The function would similarly be required to build its return
+value "in place."  There are a lot of details to work out,
+but it would make an interesting "amendment" proposal.  But
+that is certainly for another day ;-).
+
+> Erhard
+
+****************************************************************
+
+From: 	Randy Brukardt
+Sent: 	Tuesday, April 20, 1999 12:32 PM
+
+>While I agree it would be nice to have this included in the Corrigendum
+>(though hardly earth-shattering if it isn't), I'm not sure why you're so
+>concerned about "enforcing the ruling".  It seems that the only thing
+>you can reasonably test is that Initialize doesn't get optimized away,
+>assuming that we go with the "new" revised rules (that should be tested
+>I suppose, but I'm not too worried that compilers are going to violate
+>it if that's what we decide).  If we stick with the current write-up
+>for AI-147, then what are you going to "enforce", that compilers don't
+>do too much optimization?  That doesn't seem worth expending the effort
+>to test, even if feasible.
+
+Yes, we need to test that compilers don't take advantage of  the repealed parts
+of 7.6(21). (And if the AI is rewritten to prohibit optimization of Initialize,
+that should be tested as well - although I think that may already be tested).
+The permissions of 7.6(21) break real, existing programs (i.e. Claw), and they
+presumably would break other people's programs as well. (This happens any time
+that objects include "self" pointers). While vendors how have Windows NT
+compilers have Claw to use as a test, those vendors without an NT compiler may
+very well get this wrong. I would happy to write an "extract of Claw" test for
+this area but I need the AI before I could consider issuing it.
+
+I realize that your and Robert think that such a test would be of little value,
+mainly because you don't expect anyone to take advantage of these permissions.
+And I would agree with you (with my compiler hat on, I wouldn't use them,
+because the tech support cost would probably outweigh any performance benefit),
+except that our experience with Claw is that people do implement these
+permissions - and sometimes go too far. And without a test, there is no possible
+way for an implementor to find out that they have gone too far until a large
+system breaks in an incredibly hard to find way.
+
+					Randy.
+
+****************************************************************
+
+From: 	Randy Brukardt
+Sent: 	Tuesday, April 20, 1999 2:32 PM
+
+>>I suppose this is not much different than requiring users to look at making
+>>locks limited, but it might force significant redesigns.
+
+>How could it force significant redesigns? Do we really have figures on how
+>important these optimizations are in any case?
+
+What I was thinking was that IF the efficiency of a library was important, then
+the implementor of that library would have to make sure that there were no
+user-defined Initialize routines. In the case of Claw, we used those because
+they were convinient, not because of any concern about abort or optimization. In
+order to remove them, we would have to figure out a different way to properly
+initialize objects. Converting existing Initialize routines into default
+initializations is a non-trivial exercise in general.
+
+The optimization we are discussing (whether a call to a user-defined initialize
+can be removed) probably isn't very useful, as it could only apply to dead
+variables. One could assume that in any truly critical code, someone would have
+checked to ensure that any unused and unneeded variables have been removed, so
+it would mainly be of benefit in reducing code size, not improving the speed.
+
+OTOH, removing calls to Adjust/Finalize pairs in assignments is pretty
+important, as the canonical semantics requires double the number of calls that
+would be reasonably expected. Of course, if no one ever actually assigns the
+objects (as often is the case with Claw objects), then it doesn't matter. But
+for types like Unbounded String, I would expect the optimizations to make a
+significant difference.
+
+I don't think anyone is arguing for the removal of all of these permissions (I
+hope!), so the case in question is simply not that important.
+
+At this point, I would prefer to simply remove the permission from the AI that
+allows the removal of user-defined initializations. It seems that there will
+always be a vocal minority against any such permission, and it simply is not
+worth holding up the completion of the AI for such a minor benefit.
+
+					Randy.
+
+****************************************************************

Questions? Ask the ACAA Technical Agent