CVS difference for ai05s/ai05-0013-1.txt

Differences between 1.1 and version 1.2
Log of other versions for file ai05s/ai05-0013-1.txt

--- ai05s/ai05-0013-1.txt	2006/04/20 05:30:40	1.1
+++ ai05s/ai05-0013-1.txt	2006/06/22 03:05:35	1.2
@@ -1,11 +1,12 @@
-!standard 7.6(9.4/2)                                 06-04-10    AI05-0013-1/01
+!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 Coextensions considered harmful
+!subject No_Nested_Finalization is difficult to enforce
 
 !summary
 
@@ -28,60 +29,64 @@
 (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 never be known if complete type is controlled.
+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
 
 (TBD.)
 
 !wording
 
-(TBD.)
+Delete 7.6(9.4/2).
 
-!discussion
+Replace D.7(4/2) with:
 
-The second question defies an obvious solution. Coextension is a run-time
-concept, so it cannot be used in a legality rule (which is how the
-definition of "needs finalization" is used). The usual solution is to
-assume the worst. How "worst" is the problem.
-
-(A) The easiest solution is to presume the current wording (modulo "limited") is
-correct. This would imply link-time checking for the No_Nested_Finalization
-restriction. 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". Yuck.
+   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
 
-(B) Another easy solution is to truly assume the worst. That is, assume that
-any designated type of an access discriminant might "need finalization". This
-would allow the "needs finalization" property to be determined at freezing time.
-However, this would ban most uses of types with access discriminants when the
-No_Nested_Finalization restriction is in use: even "acccess Integer".
-
-(C) We could assume the worst only if the designated type is not frozen at the
-point of the freezing of the type with the access discriminant. This would not
-require "access Integer" to "need finalization". However, it would make whether
-or not a particular type needs finalization very dependent on the freezing rules
-and even the order of freezing within a particular compiler. Users would not
-necessarily be able to tell what is happening.
-
-(D) We could assume the worst only for incomplete types completed elsewhere (Taft
-types and limited views). For types frozen in the current unit, the correct answer
-would be determined; for incomplete types completed elsewhere, we would have to assume
-that they need finalization. This means delaying the determination until the end of
-the containing unit in some cases; "needs finalization" could not be determined at
-the freezing point in general. [This seems like the best of the options to me,
-but it seems to be a Hobson's choice.]
-
-(E) We could ban the use of incomplete types completed elsewhere in access
-discriminants. (This is the solution we used for some other incomplete problems.)
-This is otherwise the same as (D). But it seems incompatable, and it seems
-like a large hammer for a relatively unimportant problem.
-
-(F) We could drop coextensions completely (eliminating the rule altogether, and
-the problem). But it seems too late to do that (even though the likelyhood of
-problems in practice is small). Besides, this was proposed several times during
-the Amendment work, and it didn't fly.
+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<it is a limited type that has an access discriminant whose designated
+type needs finalization; or>
+
+!corrigendum D.7(4/2)
+
+@drepl
+@xindent<Objects of a type that needs finalization (see 7.6) and access types that
+designate a type that needs finalization such objects, shall be declared only
+at library level.>
+@dby
+@xindent<Objects of a type that needs finalization (see 7.6) shall be declared
+only at library level. There are no @fa<allocator>s for an access type whose
+designated type needs finalization if the access type does not have
+library-level accessibility.>
 
 !ACATS test
 

Questions? Ask the ACAA Technical Agent