!standard 7.6(9.4/2) 06-06-21 AI05-0013-1/02
!standard D.7(4/2)
!class binding interpretation 06-04-10
!status work item 06-04-10
!status received 06-04-03
!priority Medium
!difficulty Medium
!qualifier Error
!subject No_Nested_Finalization is difficult to enforce
!summary
(See recommendation.)
!question
7.6(9.4) says that "A type is said to need finalization if ... it is a
limited type that has an access discriminant whose designated type needs
finalization."
This rule was intended to support coextensions, which get finalized when
the parent object gets finalized, and must therefore been taken into
account for computing the "needs finalization" properties. However:
1 - Coextensions can exist for nonlimited types. Thus, the "limited"
should be deleted from the wording.
2 - This property cannot be computed at the freezing point of the type
(which is the natural place to do so), as the designated type may not
be frozen yet. Indeed, there is no point during the current compilation
where it can be computed if the designated type is an incomplete one
from a limited view - it will not be known until link-time if
complete type is controlled.
This definition is used in No_Nested_Finalization; (2) implies link-time
checking. Such checking would be very expensive to build, because every
nested use of a type with an access discriminant would have to be recorded,
along with its definition, and checks would have to be made if the actual
complete type does in fact "need finalization". Is this intended? (No.)
!recommendation
Change the No_Nested_Finalization check to disallow aggregates of nested
access types which designate types that need finalization, and delete the
coextension rule from the definition of "needs finalization".
!wording
Delete 7.6(9.4/2).
Replace D.7(4/2) with:
Objects of a type that needs finalization (see 7.6) shall be declared
only at library level. There are no allocators for an access type whose
designated type needs finalization if the access type does not have
library-level accessibility.
!discussion
Directly attempting to fix problem (2) leads into a rat-hole of bad or
incompatible solutions. (If you are interested, version /01 of this AI
contained an exhausive list.)
The key is to fix the uses of "needs finalization" to consider coextensions.
There is only one use: restriction No_Nested_Finalization.
The best way to do this for No_Nested_Finalization is to make the allocators,
rather than the access types, illegal. At this point, the designated type
must be frozen, so there is no problem knowing whether it "needs finalization".
Note that the new rule uses the accessibility level of the access type of the
allocator. This is needed to take into account coextensions; the accessibility
level is determined by an extensive set of rules and we certainly don't want to
duplicate those.
!corrigendum 7.6(9.4/2)
@ddel
@xbullet
!corrigendum D.7(4/2)
@drepl
@xindent
@dby
@xindents for an access type whose
designated type needs finalization if the access type does not have
library-level accessibility.>
!ACATS test
An ACATS B-Test should be created to test these cases.
!appendix
From: Pascal Leroy
Date: Monday, April 3, 2006 8:04 AM
7.6(9.4) says that "A type is said to need finalization if ... it is a
limited type that has an access discriminant whose designated type needs
finalization."
This rule was intended to support coextensions, which get finalized when
the parent object gets finalized, and must therefore been taken into
account for computing the "needs finalization" properties. However, there
are two problems with this wording:
1 - The word "limited" should be erased because coextensions can exist for
nonlimited types in Ada 2005.
2 - There is a nasty interaction with the freezing rules. I'd like to be
able to compute the "needs finalization" property at the freezing point of
the type that has the access discriminant, but at this point the type
designated by the access discriminant may not be frozen yet (heck, it may
not even be complete if it comes from a limited view).
Comments?
****************************************************************