!standard 7.6.1(17.1/1) 07-09-13 AI05-0064-1/01 !class binding interpretation 07-09-13 !status ARG Approved 7-0-2 06-11-10 !status work item 07-09-13 !status received 07-09-12 !priority Low !difficulty Easy !qualifier Error !subject Redundant finalization rule !summary 7.6.1(17.1/1) is deleted as it is covered by 7.6.1(17.2/1). !question 7.6.1(17.1/1) appears to be either redundant with 7.6.1(17.2/1) (since expressions are often masters, and when they're not we're not finalizing anything anyway) or incomplete (because it doesn't appear to cover objects allocated for anonymous access types and the like). Is it needed? (No.) !recommendation (See Summary.) !wording Delete 7.6.1(17.1/1). !discussion The rule is not needed as the Amendment defines expressions to be masters in cases where they may have temporary objects that need finalization. Because of this definition, 7.6.1(17.2/1) applies. The rule doesn't cover all cases of anonymous objects anyway (for instance, it does not cover objects allocated for anonymous access types), and it seems to add to the complexity of the language definition to add even more cases here. Moreover, relying on 7.6.1(17.2/1) for this rule does not change the observed semantics of any program. !corrigendum 7.6.1(17.1/1) @ddel @xbullet, any other finalizations due to be performed are performed, and then Program_Error is raised.> !ACATS Test This is already covered by ACATS test C761011, and the rule change will not change the dynamic effect. !appendix From: Randy Brukardt Sent: Wednesday, September 12, 2007 11:48 PM 7.6.1(17.1/1) appears to be either redundant with 7.6.1(17.2/1) [since expressions are often masters, and when they're not we're not finalizing anything anyway] or incomplete (because it doesn't appear to cover objects allocated for anonymous access types and the like). I think it should just be deleted, and a note added to clarify that 17.2/1 covers anonymous objects as well as normal ones. (Although that really isn't necessary, it never says or implies otherwise. But still might be a good idea considering the deletion of the explicit rule). I think this rule actually was needed in Ada 95; the clarification of what is a master in the Amendment makes it redundant. I note that this whole "Bounded Error" (7.6.1(14-20) is rather suspicious, given that the only choice given is to raise Program_Error in most cases, and to ignore it in others. What's "Bounded" about that?? I'd expect a bounded error to include another choice other than Program_Error. (And it violates the principle that a bounded error always can raise Program_Error as noted in 7.6.1(20.b).) It probably should just have been normal dynamic semantics. But it isn't worth changing this - insufficiently broken. **************************************************************** From: Tucker Taft Sent: Thursday, September 13, 2007 7:53 AM I agree with both of your points, though when you ask what's "bounded," it seems that it is "too" bounded, rather than not bounded enough. It seems to be 7.6.1(16/2) that is the only one that has multiple possibilities, and perhaps that is the only paragraph that would have been awkward to include in "normal" dynamic semantics. I think the other reason we might have preferred to put these paragraphs under "bounded errors" rather than "dynamic semantics" is that we use the phrase "due to be performed" without really defining it. We tend to be a bit looser in our bounded-error wording. **************************************************************** From: Randy Brukardt Sent: Thursday, September 13, 2007 7:23 PM Yes, "too bounded" (to a single possibility), rather than not bounded enough. Another possibility for why it is a bounded error is that you may have originally had looser rules for where the error is detected (I'm too lazy to look it up right now), such that they made sense as a bounded error -- and they never got changed later. In any case, insufficiently broken. ****************************************************************