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

--- ai05s/ai05-0052-1.txt	2007/05/26 01:44:00	1.1
+++ ai05s/ai05-0052-1.txt	2007/10/26 01:37:57	1.2
@@ -1,4 +1,4 @@
-!standard 3.10.2(10.1/2)                            07-05-15    AI05-0052-1/01
+!standard 3.10.2(10.1/2)                            07-10-25    AI05-0052-1/02
 !class binding interpretation 07-05-15
 !status work item 07-05-15
 !status received 07-05-14
@@ -9,7 +9,9 @@
 
 !summary
 
-*TBD*
+An allocator that is used to create a coextension is illegal if
+the designated type might be limited but the enclosing object might be
+of a nonlimited type.
 
 !question
 
@@ -27,12 +29,28 @@
 
 !recommendation
 
-Not clear. Ban non-limited coextensions? See discussion for ideas.
+Statically reject an allocator used to create a coextensions if
+the designated type might be limited but the enclosing object might be
+of a nonlimited type.
 
 !wording
 
-*TBD*
+Add after 4.8(5.3/2):
 
+If the designated type of the type of the allocator is limited, then
+the allocator shall not be used to define the discriminant of an
+object, unless the object is of a task, protected, or explicitly limited
+record type.
+
+AARM Note: Because coextensions work very much like parts, we don't want
+users creating limited coextensions for nonlimited types.  This would
+be similar to extending a nonlimited type with a limited component.  We
+check this on the allocator.  Note that there is an asymmetry in what
+types are considered limited; this is required to preserve privacy.  We
+have to assume that the designated type might be limited as soon as we
+see a limited partial view, but we want to ensure that the containing
+object is of a truly limited type.
+
 !discussion
 
 Consider the following example:
@@ -75,43 +93,58 @@
 
 In the case of the preceding example, some kind of restriction is needed
 if a caller of Pkg.F is to be able to assume that it does not need to
-cope with tasks. This could be accomplished through some combination of
-static and dynamic checking. The other choice, of course, is to leave the
+cope with tasks. The other choice, of course, is to leave the
 language unchanged and simply pay the performance cost for this feature.
 
 Informally, an object's coextension can be thought of as being a "part" of
 of the object. This is the model that the language designers had in mind.
 
 An extension of a nonlimited type cannot add a limited component. Leaning
-on our informal definition of "part" as it relates to coextensions might
-lead to the conclusion that an extension of a nonlimited type should not
-have an access discriminant which designates a limited type (which can
-be checked statically), or at least that such an access discriminant should
-not designate a coextension (which cannot). Consider, for example, a
-generic body which allocates a coextension for an object of a formal
-limited type; the corresponding actual type might or might not be limited.
+on our informal definition of "part" as it relates to coextensions 
+leads to the conclusion that an extension of a nonlimited type should not
+have an access discriminant which designates a limited type, or at least
+that such an access discriminant should not designate a coextension. Checking
+rules like these is problematical, because it is not always known whether
+or not a type is limited. Consider, for example, a generic body which
+allocates a coextension for an object of a formal limited type; the
+corresponding actual type might or might not be limited.
 
-A more liberal approach would be to disallow access-to-limited non-inherited
+Another possible approach would be to disallow access-to-limited non-inherited
 access discriminants for a nonlimited extension unless the parent type already
 has such a discriminant. The general idea is to require the decision about the
 legality of task "parts" for a nonlimited type to be made when the nonderived
-root of the derivation hierarchy is declared. Unfortunately, this approach
-probably only makes sense if it can be checked statically and it appears
-that it cannot.
+root of the derivation hierarchy is declared.
 
-The simplest solution might be a runtime check when a coextension is allocated
+The easiest solution would be a runtime check when a coextension is allocated
 which fails if the coextension's type has a part that is of a task, protected,
 or explicitly limited record type and the owning object's type does not. In
 the case of the preceding example, this check would raise an exception at the
-point of the allocator within Pkg.F . For implementations which do not generate
+point of the allocator within Pkg.F. For implementations which do not generate
 shared code for generics, the outcome of this check would always be known at
 code-generation time.
 
-Still, a static check which is somewhat conservative might be preferable to a
-more precise dynamic check.
+However, we generally prefer compile-time checks to runtime checks, especially
+in cases where there is no acceptable implementation. Thus, we prefer a static
+check. In order to avoid rejecting useful types in the absence of coextensions,
+we chose to make a conservative check on the creation of coextensions, rather
+than limiting the kinds of allowable discriminants. It is perfectly reasonable
+to have a discriminant that accesses an existing task object, and there is no
+reason to disallow such constructs.
+
+In order for the check to work, we have to make any coextension allocator for
+a type that *might* be limited illegal unless it is a coextension of a type
+that is *known* to be limited. That is, there cannot be a case where the real
+coextension type turns out to be limited and the real type of the type with
+the access discriminant is not limited.
+
+Note that this rule in incompatible with Ada 95 in unusual cases; those
+where a coextension is created with a limited type (including limited private types)
+and the type with the discriminant is not known to be limited (usually a limited
+private type.) Coextension use is rare enough that this is not that important.
 
 !ACATS test
 
+An ACATS B-Test is needed to check this rule.
 
 !appendix