Version 1.4 of ai05s/ai05-0064-1.txt

Unformatted version of ai05s/ai05-0064-1.txt version 1.4
Other versions for file ai05s/ai05-0064-1.txt

!standard 7.6.1(17.1/1) 07-09-13 AI05-0064-1/01
!class binding interpretation 07-09-13
!status Amendment 201Z 08-11-26
!status WG9 Approved 08-06-20
!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)

Delete the paragraph:

For a Finalize invoked as part of the finalization of the anonymous object created by a function call or aggregate, 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.

****************************************************************

Questions? Ask the ACAA Technical Agent