CVS difference for ais/ai-10318.txt
--- ais/ai-10318.txt 2004/09/04 01:13:47 1.6
+++ ais/ai-10318.txt 2004/10/05 22:49:21 1.7
@@ -26,8 +26,9 @@
!class amendment 02-10-09
+!status Amendment 200Y 04-09-23
+!status ARG Approved 5-0-4 04-09-23
!status work item 04-07-28
-!comment !status Amendment 200Y 04-07-02
!status ARG Approved 9-0-2 04-06-17
!status work item 03-05-23
!status received 02-10-09
@@ -207,23 +208,6 @@
- If the result subtype of a function is limited at the point where the
- function is frozen (see 13.14), the result subtype shall be constrained.
- AARM NOTE:
- This rule is not a necessary restriction, but simplifies implementation
- dramatically, since it means the caller can allocate space for the result
- object, perform all "implicit" initializations of task and protected
- components, worry about accessibility levels for access discriminants,
- AARM Ramification:
- Note that this rule is defined at the point where a function is frozen
- rather than at the point of the function declaration, to ensure we are
- talking about the type characteristics visible inside the enclosing package,
- rather than the characteristics visible to the caller. Of course
- compilers are encouraged to signal the error as soon as possible.
A return_statement shall be within a callable construct, and it applies to
the innermost callable construct or extended_return_statement that contains
it. A return_statement shall not be within a body that is within the
@@ -496,8 +480,8 @@
"really" limited objects. See the discussion below about implementation
-The proposed syntax for extended return statements was discussed a year or so
-ago, but when this AI was first written up, we proposed instead a revised
+The syntax for extended return statements was initially proposed early on,
+but when this AI was first written up, we proposed instead a revised
object declaration syntax where the word "return" was used almost like the word
"constant," as a qualifier. This was somewhat more economical in terms of
syntax and indenting, but was not felt to be as clear semantically as this
@@ -540,13 +524,68 @@
compilers already have to deal with returning non-limited controlled
objects, so presumably this won't create an insurmountable burden.
-If a limited result subtype could be unconstrained, the implementation
-might be significantly more complex. The details are discussed in
-AI-318-1. We do not allow this in this proposal (nor in that one, for
-that matter). Note that by disallowing unconstrained result types,
-we also eliminate issues relating to access discriminants of
-limited types, which have special accessibility checking issues.
+If the result subtype is unconstrained, then there are two basic possibilities:
+ 1) The target object's (nominal) subtype is definite, and either constrained
+ or the size of the object is independent of the constraints (e.g.
+ allocate-the-max is used for the object); the target object might be a
+ component of a larger object.
+ 2) The target object's nominal subtype is unconstrained, and its size
+ is to be determined by the result returned from the function;
+ the target object must be a stand-alone object, or an "entire"
+ heap object.
+In the first case, the caller determines the size of the target object and
+can allocate space for it; in the second, the caller cannot
+preallocate space for the target object, and must rely on the called
+routine allocating space for it in an "appropriate" place.
+The code for the called routine must handle both of these cases.
+One reasonable way to do so is for the caller to provide a
+"storage pool" for the result. In the first case, this storage
+"pool" has space for exactly one object of a given maximum size.
+It's Allocate routine is trivial. It just checks to see if the
+size is no greater than the space available, and then returns the
+preallocated (target) address.
+In the second case, the storage pool is either the storage pool
+associated with the initialized allocator at the call site,
+or a storage pool that represents a secondary stack, or equivalent,
+used for returning objects of unknown size from a function.
+In either case, the function would return the address of the new
+A "bare" storage pool may not be enough in general. If the type
+has any task parts, then these tasks must be placed on an activation
+list determined by the calling context. They may also be linked onto a
+master record of some sort, unless this is deferred until
+activation occurs. Note that the tasks cannot be activated
+until after returning from the call, since they may have
+to be activated in conjunction with other tasks having the
+If the type has any controlled or protected parts, then the object
+as a whole, or the individual parts, may need to be added to
+a cleanup list determined by the calling context.
+If the type has any access discriminants, then some kind of
+accessibility level will need to be provided, since the access
+discriminant may only be initialized to point to an object
+whose accessibility level is no deeper than that of the
+storage pool where the new object is being allocated.
+What this means is that rather than passing just a reference
+to a storage pool, it is more likely the caller will pass
+a reference to a structure which in turn refers to:
+ - a storage pool,
+ - an accessibility level,
+ - an activation list,
+ - the associated master,
+ - a cleanup list
Supporting a function result of an anonymous access type presents no
special challenges since we have defined the accessibility level of
the result type to be the same as that as the associated function
@@ -574,7 +613,7 @@
It has been argued that this requirement is not needed because any such copies
are semantically neutral. But no copies of a self-referencing object could
-every really be semantically neutral. Moreover, the definition of object
+ever really be semantically neutral. Moreover, the definition of object
creation in 3.3(19) says that the subcomponents are assigned from the
expression already evaluated. This clearly must be superceded.
@@ -666,9 +705,6 @@
to> the innermost one. A @fa<return_statement> shall not be within a body that
is within the construct to which the @fa<return_statement> applies.
-If the result subtype of a function is limited at the point where the
-function is frozen (see 13.14), the result subtype shall be constrained.
A @fa<return_statement> shall be within a callable construct, and it applies to
the innermost callable construct or @fa<extended_return_statement> that
contains it. A @fa<return_statement> shall not be within a body that is within
Questions? Ask the ACAA Technical Agent