CVS difference for ais/ai-00083.txt

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

--- ais/ai-00083.txt	2000/04/11 19:36:33	1.10
+++ ais/ai-00083.txt	2000/04/14 01:45:06	1.11
@@ -1,4 +1,4 @@
-!standard 07.06    (21)                               99-11-18  AI95-00083/05
+!standard 07.06    (21)                               00-04-12  AI95-00083/06
 !standard 07.06.01 (20)
 !class binding interpretation 95-07-27
 !status Corrigendum 2000 99-07-28
@@ -12,8 +12,9 @@
 When an (extension) aggregate of a controlled type is assigned other
-than an assignment or return statement, the aggregate is built "in place";
-Finalize and Adjust are not called on the object as a whole.
+than by an assignment or return statement, the aggregate is built "in place".
+No temporary object is create and Adjust is not called on the object as a
@@ -118,10 +119,10 @@
 @i<@s8<Implementation Requirements>>@hr
 For an aggregate of a controlled type whose value is assigned, other than
-@fa<assignment_statement> or @fa<return_statement>, the implementation shall
-not create a separate anonymous object for the aggregate. The aggregate value
-shall be constructed directly in the target of the assignment operation, and
-Adjust is not called on the target object.
+by an @fa<assignment_statement> or a @fa<return_statement>, the implementation
+shall not create a separate anonymous object for the aggregate. The aggregate
+value shall be constructed directly in the target of the assignment operation
+and Adjust is not called on the target object.
 !ACATS test
@@ -1301,6 +1302,180 @@
     -- attempt to call Initialize here would P_E!
 Stupid place to test a core language rule, if that was the intent.
+From: Pascal Leroy
+Sent: Tuesday, March 28, 2000 1:51 AM
+> I thought that was what was covered by AI-197 (now folded into AI-83) and it
+> ought to be covered by the Corrigendum wording for AI-83. Are you sure it
+> isn't? Are you looking at the version I created last November, and not some
+> old, obsolete version??
+You're right, I was stupidly looking at an old version, the one that has been
+approved by WG9 in 1995, and which we implemented.  The latest wording correctly
+covers the case of a controlled subaggregate.
+From: Tucker Taft
+Sent: Monday, April 03, 2000 9:30 AM
+Erhard Ploedereder wrote:
+> ...I think it is absolutely counter-productive
+> to say that, for now, we should mandate P_E to be raised here, when the
+> official language fix is just around the corner.
+Independent of the bigger issues, I would certainly find it silly
+for us to start mandating Program_Error for the most simple of these
+Furthermore, my impression as an implementor, is once you support the
+simple case of "Obj : constant blah := (aggregate)" handling the
+more general case is a relatively small step.  In fact, it could make
+things more complicated for the compiler to disallow Program_Error
+for the simple case, and then require it for the more complex cases.
+I could see in a transitional period disallowing Program_Error in
+the simple case, and making it implementation-defined for the more
+complex cases, with the goal of shifting to disallowing Program_Error
+in all cases eventually.  In other words, the initial ACATS test would
+check only the simple cases for lack of P_E.  Eventually, ACATS tests for
+the more complex cases would be created as well.
+From: Robert Dewar
+Sent: Wednesday, April 05, 2000 1:08 PM
+Let's get back to the substantive issue here, which is what the
+subject is about. Should this be an NBI or not.
+My argument that it should not be binding is that it seems clearly
+to be a change int he language. I have not seen a good argument
+that this interpretation was intended or can be read into the RM.
+On the contrary it seems pretty clear that the RM demands program error
+I am not at all convinced that a proper analysis of implementation
+difficulty has been carried out.
+The only time we can MANDATE what are clear changes are when we know
+there is no implementation burden, e.g. making Bit_Order static.
+From: Erhard Ploedereder
+Sent: Wednesday, April 05, 2000 5:32 PM
+The RM doesn't demand P_E. P_E is the canonical semantics, but 7.6(21)
+explicitly gives the permission to do as the AI is now mandating.
+Raising P_E implies for the user that the declaration of a non-limited
+controlled types with user-defined Initialize and Adjust and an object
+creation of that type must not be in the same package spec (or list of basic
+decl. items).
+It's a pretty nasty portability problem if one implementation allows
+this for initialized objects and the other always raises P_E for this.
+The change by the AI is upward-compatible for the user (except for extremely
+pathological examples). And, it will be in the Technical Corrigendum.
+All this argues for implementers to make the change ASAP.
+Traditionally, "non-binding" was applied to situations, where
+   - it was an upward-incompatible change,
+   - it directly contradicted the RM, or
+   - it was a severe implementation burden.
+The first does not apply; the second (arguably) does not really apply,
+given 7.6(21) and the derivative nature of the elaboration error that
+arises; no strong argument was made so far for the third case.
+So I don't think that a NBI rating is warranted.
+Whether the ACATS includes a rated test for it at day zero or after some
+suitable phasing-in period, is a different question. Needless to say, I'm
+heavily against the day zero approach, which is unreasonable.
+From: Robert Dewar
+Sent: Wednesday, April 05, 2000 5:47 PM
+<<no strong argument was made so far for the third case.>>
+I hereby make that case, we have not done the analysis in GNAT to know how
+difficult this is. It is by no means trivial, we did investigate this
+some time ago, and decided that the difficulty did not justify the
+technical gain at the time, and that there was no significant customer
+demand for this feature.
+I object to changes in the language which force vendors to deploy resources
+in a manner that is not consistent with best serving our customers. I prefer
+that *we* be the judge of how best to serve our customers when it comes to
+improvements in our technology, not the ARG!
+What the NBI designation does here is to say, "sorry, we were wrong,
+this implementation permission should have been a requirement, and in
+the next version of the language it will be a requirement."
+The trouble with the ARG is that it has a VERY narrow range of vision.
+When it comes to finding a bug in the language and fixing it, that very
+narrow range of vision is fine.
+When it comes to deciding what enhancements to mandate to the language,
+this narrow vision is very damaging, because it leads the ARG to decide
+that a particular feature is desirable in isolation. But such isolated
+decisions never make sense. Every improvement you make damages the
+Ada tecnologies out there by siphoning off effort from possibly more
+important features, and the ARG is in no position to make this tradeoff.
+The language definition is quite clear, I see no convincing argument in the
+AI, or elsewhere to change the language here. Yes, I see an argument that
+the language would be more useful if this change is made, but that same
+argument can be made for hundreds of other possible changes!
+From: Tucker Taft
+Sent: Wednesday, April 05, 2000 6:09 PM
+Robert Dewar wrote:
+> ...
+> The only time we can MANDATE what are clear changes are when we know
+> there is no implementation burden, e.g. making Bit_Order static.
+I think we should mandate changes when we think there is a clear bug
+in the language.  To me this is a bug.  People bump into this frequently
+when they try to do very "normal" things with controlled types
+(e.g. define a Null_Unbounded_String).  We simply goofed when we wrote the RM.
+This isn't an enhancement in my view, but rather an important bug fix.
+In general, the burden of proof of implementation problems has to be on the implementor,
+not on the ARG.  Clearly several compilers have already implemented some
+version of this.  It is hopeless for the ARG to do implementation burden
+analysis on compilers they didn't write.  If there is an ARG member who
+knows of a serious implementation burden, then by all means speak up.
+I haven't heard anything like that yet.
+From: Robert Dewar
+Sent: Wednesday, April 05, 2000 7:22 PM
+We are doing an analysis right now of the implementation burden.
+I must say that I don't think of this as a bug in the language. Yes, it was
+a bit of bad design, but if we are allowed to fix bad design decisions, I
+have MUCH more important candidates, for example, the horrible non-upward
+compatible design of fixed-point, which continues to cause us grief, and
+the goof on the definition of Size which ends up being THE major non
+compatibility between Ada 83 and Ada 95. These are FAR more serious
+mistakes in the RM, but I am NOT suggesting fixing them (well I think
+we need to fix them, but I would not dream of fixing them by changing
+the language, rather than extending it).

Questions? Ask the ACAA Technical Agent