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

Differences between 1.3 and version 1.4
Log of other versions for file ai05s/ai05-0151-1.txt

--- ai05s/ai05-0151-1.txt	2009/06/08 03:18:32	1.3
+++ ai05s/ai05-0151-1.txt	2009/11/04 01:27:15	1.4
@@ -1,4 +1,5 @@
-!standard  3.10.1(2/2)                                 09-06-06    AI05-0151-1/03
+!standard  3.10.1(5/2)                                 09-11-03    AI05-0151-1/04
+!standard  3.10.1(10/2)
 !class Amendment 09-04-29
 !status work item 09-04-29
 !status received 09-04-29
@@ -16,7 +17,7 @@
 The limited with clause makes incomplete views of types visible.
 Tagged incomplete types are useful for formal parameters, but
 most other incomplete types are pretty much useless, except
-as the designated type of an access type.  It would be nice
+as the designated type of an access type. It would be nice
 if a type declared in a package named in a limited with
 clause could be used somehow, if only as a parameter type.
 
@@ -31,16 +32,72 @@
 For tagged incomplete types, we will continue to permit them as
 parameters even in calls and in a body, provided the incomplete type
 comes from a limited view of a package, rather than from an incomplete
-type declaration.  For non-tagged incomplete types, they will not be
-permitted in calls or in a body.  If the parameter or result type was
+type declaration. For non-tagged incomplete types, they will not be
+permitted in calls or in a body. If the parameter or result type was
 incomplete at the point of declaration, any call or the body must be
 within the scope of a *non* limited view of the package defining the
 type.
 
 !wording
 
-** TBD **
+Revise 3.10.1(5/2 - 10/2):
 
+  A name that denotes an incomplete view of a type may be used as follows: 
+
+    * as the subtype_mark in the subtype_indication of an
+    access_to_object_definition; the only form of constraint allowed in
+    this subtype_indication is a discriminant_constraint (a
+    null_exclusion is not allowed);
+
+    * as the subtype_mark in the subtype_indication of a
+    subtype_declaration; the subtype_indication shall not have a
+    null_exclusion or a constraint;
+
+    * as the subtype_mark in an access_definition.
+    
+   {* as the subtype_mark defining the subtype of a parameter or result 
+      in a profile occurring within a basic_declaration;
+        AARM Note: As opposed to in the profile for a body.} 
+
+  If such a name denotes a tagged incomplete view, it may also be used:
+
+    * as the subtype_mark defining the subtype of a parameter in [a
+    formal_part] {the profile for a subprogram_body, entry_body, or
+    accept_statement};
+
+    * as the prefix of an attribute_reference whose attribute_designator
+    is Class; such an attribute_reference is restricted to the uses
+    allowed here; it denotes a tagged incomplete view.
+
+  [If such a name occurs within the declaration list containing the
+  completion of the incomplete view, it may also be used:
+
+    * as the subtype_mark defining the subtype of a parameter or result
+    of an access_to_subprogram_definition or an access_definition for an
+    access-to-subprogram type.]
+
+  If any of the above uses occurs as part of the declaration of a
+  primitive subprogram of the incomplete view, {or as part of an
+  access_to_subprogram_definition or an access_definition for an
+  access-to-subprogram type, then the primitive subprogram declaration
+  or the access-to-subprogram type definition shall occur within the
+  declaration list immediately containing} [and the declaration occurs
+  immediately within the private part of a package, then] the completion of
+  the incomplete view [shall also occur immediately within the private
+  part; it shall not be deferred to the package body].
+
+  No other uses of a name that denotes an incomplete view of a type are
+  allowed.
+  
+  A prefix that denotes an object shall not be of an incomplete view.
+  {An actual parameter in a call shall not be of an untagged incomplete
+  view. The result object of a function call shall not be of an
+  incomplete view.  
+  
+  A name that denotes an object of an incomplete view is defined to be
+  of a limited type. [Redundant: Hence, the target of an assignment
+  statement shall not be of an incomplete view.]}
+
 !discussion
 
 This proposal originally focused on a concern that a "limited with"
@@ -48,14 +105,14 @@
 explicit conversion and/or anonymous access types in the clients.  We
 originally proposed to allow "incomplete access types" to be used as
 formal parameters and result types, to avoid the need for all of the
-conversion.  However, after analysis of the issues involved, it became
+conversion. However, after analysis of the issues involved, it became
 clear that it was possible to generalize, and in some ways simplify, the
 proposal by allowing the use of *any* incomplete type as a parameter or
 result type, provided that the full definition was available at the
 point of call or at the definition of the body of the subprogram.
 
 An incomplete type is OK as a parameter or result since, until there is a
-call, there is no need to know the representation of the type.  This is
+call, there is no need to know the representation of the type. This is
 in contrast to the case with components, where an aspect clause would
 need to be obeyed to ensure that streaming, aliased objects, etc., work
 as expected.
@@ -71,12 +128,12 @@
 
 Note that we have chosen to allow incomplete types as function results,
 even though we restricted tagged incomplete types to being parameters
-only.  This seems inconsistent.  Why should tagged incomplete types be
+only. This seems inconsistent. Why should tagged incomplete types be
 *more* restrictive than incomplete types in general? Well, they
 shouldn't be, so with this proposal, the only advantage a tagged
 incomplete type will have is that a call or body *will* be permitted on
 a subprogram with tagged incomplete parameters, provided they are not
-controlling parameters.  Tagged or untagged incomplete types will be
+controlling parameters. Tagged or untagged incomplete types will be
 permitted as both parameters and results when declaring a subprogram.
 
 The net effect of this proposal is that changing a "with" to a "limited with"
@@ -89,7 +146,7 @@
 
 I wonder whether we could have generic formal incomplete
 types as a way to allow instantiation with a private type before
-it is completely defined.  This might be sufficient for a "signature"
+it is completely defined. This might be sufficient for a "signature"
 generic.
 
 !example
@@ -453,6 +510,17 @@
 
 I'm not sure this really works very well in practice, but it surely was intended
 to be possible.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Tuesday, November 3, 2009  10:24 AM
+
+Here is the AI allowing incomplete types within a profile for a subprogram/entry
+declaration, provided the full type is visible at the point of the body and at each
+call.
+
+[This is version /04 of the AI - ED.]
 
 ****************************************************************
 

Questions? Ask the ACAA Technical Agent