CVS difference for ais/ai-40217.txt

Differences between 1.3 and version 1.4
Log of other versions for file ais/ai-40217.txt

--- ais/ai-40217.txt	2003/02/05 21:45:39	1.3
+++ ais/ai-40217.txt	2003/03/22 04:18:07	1.4
@@ -1,4 +1,4 @@
-!standard 03.10.01   (02)                           03-01-16  AI95-00217-05/01
+!standard 03.10.01   (02)                           03-03-18  AI95-00217-05/02
 !standard 03.10.01   (03)
 !standard 03.10.01   (04)
 !standard 03.10.01   (05)
@@ -9,35 +9,30 @@
 !standard 10.01.02   (03)
 !standard 10.01.02   (04)
 !standard 10.01.02   (08)
-!standard J.10       (00)
+!standard 10.02      (04)
+!standard J.11       (00)
 !class amendment 03-01-16
 !status work item 03-01-16
 !status received 03-01-16
 !priority Medium
 !difficulty Hard
-!subject Type stubs with abstracted packages
+!subject Type stubs with limited context clauses
 
 !summary
 
-A pair of new constructs, called "type stub"s and "abstract clause"s are added
-to the Standard to provide a solution to the "mutually recursive types across
-packages" problem.
-
-An abstract clause specifies an "abstracted package". Details from this
-package can be used in the current compilation unit without creating a
-semantic dependence. An abstracted package is specified by its full expanded
-name.
+A pair of new constructs, called "type stub"s and "limited with clause"s are
+added to the Standard to provide a solution to the "mutually recursive types
+across packages" problem.
+
+A limited with clause makes a compilation unit available for limited use.
+Some details of such a unit can be used in the current compilation unit without
+creating a semantic dependence.
 
 A type stub is a kind of incomplete type declaration which is completed in
-an abstracted package. Compile-time checks are performed on use of the
-name introduced by the type stub that the completion is "available" and
+a package specified by a limited with. Compile-time checks are performed on use
+of the name introduced by the type stub that the completion is "available" and
 "appropriate" (see !proposal for details).
 
-A concept of a "tagged incomplete" type is introduced, which is a type that has
-the same restrictions as an incomplete type except that it may also be used for
-a formal or actual parameter.  A corresponding tagged type stub is defined,
-with the corresponding restrictions.
-
 !problem
 
 Ada allows mutually recursive types to be declared only if they are all
@@ -50,115 +45,96 @@
 primitive operations with (pointers to) each other as parameters), and to do
 this in a way that doesn't place any undue restrictions on the programmer.
 
-For mutually recursive types, it is valuable if subprogram parameters may be of
-the type itself, rather than only an access to the type. However, for most
-types, it may be necessary to see the full definition to know how parameters of
-the type are passed. However, because tagged types are always passed by
-reference, there is no implementation difficulty in allowing them to be used as
-parameters even when the full definition of the type is not available.  Hence,
-it makes sense to relax the rule for using incomplete types that are known to
-be tagged, to allow them as formal and actual parameters, since from a code
-generation point of view they are essentially equivalent to access parameters.
-
 !proposal
 
 The syntax for a context_item is amended as follows:
 
-   context_item ::= with_clause | use_clause | abstract_clause
-   abstract_clause ::= [PRIVATE] ABSTRACT OF abstracted_package_specifier;
-   abstracted_package_specifier ::=
+   context_item ::= with_clause | use_clause | limited_with_clause
+   limited_with_clause ::= [PRIVATE] LIMITED WITH limited_unit_specifier;
+   limited_unit_specifier ::=
        identifier
-     | abstracted_package_specifier . identifier;
+     | limited_unit_specifier . identifier;
 
-A package specified in an abstract_clause is called an "abstracted package".
-The abstracted package does not create a semantic dependence on the
-specified package.
+The limited_with_clause does not create a semantic dependence on the
+specified unit. The specified unit can only be used only in contexts
+that specifically allow the use of limited_unit_specifiers; this clause
+do not declare a name that can be generally used. The limited_unit_specifier
+specifies the full expanded name of a compilation_unit. (It's harmless to
+allow non-packages here, and we can't check anyway.)
 
-The abstract_package_specifier can be used within the declarative region of the
+The limited_unit_specifier can be used within the declarative region of the
 compilation_unit, unless the keyword private appears, in which case it may
 only be used in private parts and bodies. (This is the same rule as for
-"private with".)
+"private with", see AI-262.)
+
+The unit specified by the limited_with_clause is needed if the compilation
+unit on which it appears is needed - see 10.2. (This insures that the
+completion appears in the partition.)
+
+A post-compilation check is made that any unit which has a limited_with_clause
+is included in the semantic closure of the unit named by the
+limited_unit_specifier. This includes a check that limited_unit_specifier
+specifies the full expanded name of a library compilation_unit (starting with a
+root library unit, and using no renaming declarations).
+(This allows most checks to be accomplished at the point of completion, and
+also simplifies the implementation for some compilers.)
 
-An abstracted package is intended to be used to declare that a second package
-(called the "package abstract") is an abstract of the abstracted package. (Note:
-this paragraph describes the model and intended use of the proposal, but plays
-no role in the proposal itself. In particular, we define "package abstract"
-solely to explain the intended model more easily.) A
-package abstract exports a subset of the capabilities of the abstracted
-package, but does not create a semantic dependence on it. Thus, it can be used
-to implement mutually dependent types. A package abstract is a completely
-normal package, and thus has no restrictions on what it can do.
 
 The syntax for an incomplete type declaration is amended as follows:
 
    incomplete_type_declaration ::=
-       TYPE defining_identifier [discriminant_part] [IS TAGGED]
+       TYPE defining_identifier [discriminant_part];
      | type_stub;
 
-If the words IS TAGGED appear, the type is a tagged incomplete type. Otherwise,
-the type is a non-tagged incomplete type. In addition to places where a
-(non-tagged) incomplete type may be used, a tagged incomplete type may be used
-as a formal parameter type, and as an actual parameter that is a dereference of
-an access-to-tagged-incomplete value. The attribute 'Class is defined for
-(specific) tagged incomplete types. (The use of 'Class with non-tagged
-incomplete types is considered obsolescent; such non-tagged incomplete types
-must be completed with a tagged type.) The class-wide type denoted by the Class
-attribute of an incomplete tagged type is also an incomplete tagged type. An
-incomplete tagged type declaration must be completed by a tagged type
-declaration.
+[Note: tagged incomplete types are now defined in AI-326.]
 
 A new kind of incomplete type declaration is added:
 
    type_stub ::=
        TYPE defining_identifier [discriminant_part]
-               IS [ TAGGED ] SEPARATE IN abstracted_package_specifier;
+               IS [ TAGGED ] SEPARATE OF limited_unit_specifier . type_identifier;
 
 A type_stub introduces an incomplete type whose completion occurs in the
-package identified by the abstracted_package_specifier. The abstracted package
-must appear in an abstract_clause for the compilation_unit. If the word TAGGED
-appears, the type is a tagged incomplete type. The abstracted_package_specifier
-is not subjected to the name resolution rules at the place of the type_stub.
+unit identified by the limited_unit_specifier, and whose defining_identifier
+is type_identifier. The limited_unit_specifier must appear in a
+limited_with_clause for the compilation_unit. If the word TAGGED
+appears, the type is a tagged incomplete type (see AI-326). The
+limited_unit_specifier is not subjected to the name resolution rules at the
+place of the type_stub.
 
 In order to be a completion, the completing type declaration must be in the
-visible part of the abstracted package, must not be an incomplete type
-declaration, and must satisfy all other rules for incomplete type completion.
-This rule is enforced when the incomplete type is used in a context where a
-complete type is required.
-
-When the name introduced by a type stub is used in a context where it must
-match some other type, if the other type is a type stub, a check is made they
-have the same abstracted_package_specifier. If the other type is a complete
-type, a check is made that the the full expanded name of the package where the
-other type is declared matches that of the type stub's
-abstracted_package_specifier, and the other type is an acceptable completion of
-the incomplete type.
+visible part of the unit specified by the limited_unit_specifier,
+must not be an incomplete type declaration, and must satisfy all other rules
+for incomplete type completion. A check is also made that there is no more
+than one type stub for the completing type declaration. (These checks can be
+made in the compilation unit containing the completing type declaration,
+because any type stubs must be in the semantic closure of the unit by the
+rule above.) Each type stub that specifies a particular unit must be
+completed in that unit.
 
 When a name introduced by a type stub is used in a context where a complete
-type is required, other than where it must match a particular complete type
-(which is described above), a check is made that the usage place is within the
-immediate scope of the completion, or is within the scope of a with clause that
-mentions the package identified by the type stub's abstracted_package_specifier.
-A check is made that the completion is not an incomplete type declaration, and
-satisfies the other requirements for completing an incomplete type. A check is
-made that the abstracted_package_specifier provides the full expanded name of
-the completing package -- it must not involve any renamings. (This eliminates
-ambiguities when checking for type matching of two type stubs with the same
-completion, and simplifies the check whether a completing package is
-"available.")
+type is required (which is described above), a check is made that the usage
+place is within the immediate scope of the completion, or is within the scope
+of a with clause that mentions the unit identified by the type stub's
+limited_unit_specifier.
 
+Deferences of an access-to-incomplete type are allowed in limited additional
+contexts.
+
 !wording
 
 Replace 3.10.1(2):
 
-   incomplete_type_declaration ::= TYPE defining_identifier [discriminant_part] [IS TAGGED];
+   incomplete_type_declaration ::= TYPE defining_identifier [discriminant_part];
      | type_stub
 
-   type_stub ::= TYPE defining_identifier [discriminant_part] IS [TAGGED]
-     SEPARATE IN abstracted_package_specifier;
+   type_stub ::=
+       TYPE defining_identifier [discriminant_part] IS [ TAGGED ]
+            SEPARATE OF limited_unit_specifier . type_identifier;
 
-   abstracted_package_specifier ::=
+   limited_unit_specifier ::=
        identifier
-     | abstracted_package_specifier . identifier;
+     | limited_unit_specifier . identifier;
 
 Modify 3.10.1(3):
 
@@ -167,131 +143,118 @@
 
 Insert 3.10.1(3.1):
 
-        A type_stub includes a abstracted_package_specified which specifies the
-	full expanded name of the package in which its completion is expected
-	to occur. [Certain uses (see below) of a name that denotes the
-	type_stub or a value of an access type that designates the type_stub,
-	require that the completion exist.] In these cases, the completion
-	shall occur in the visible part of the specified package, and be a
-	type_declaration other than an incomplete_type_declaration; the
-	abstracted_package_specifier shall be the full expanded name of this
-	package (starting with a root library unit, and using no renaming
-	declarations), and the package shall be a library package.
+        A type_stub includes a limited_unit_specifier which specifies the
+	full expanded name of the compilation unit in which its completing
+        type is expected to occur. [Certain uses (see below) of a name that
+        denotes the type_stub or a value of an access type that designates the
+        type_stub, require that the completing type exist.] For a type_stub,
+        the completing type shall occur in the visible part of the specified
+        unit, and be a type_declaration other than an
+        incomplete_type_declaration; the type_identifier shall be the same as
+        the defining_identifier of the completing type. Each completing type
+        shall have no more than one type_stub.
 
 Modify 3.10.1(4):
 
-   Add a new first sentence:
-
-        If an incomplete_type_declaration includes the keyword TAGGED, then a
-        type_declaration that completes it shall declare a tagged type.
-
    Replace all occurrences of "full_type_declaration" with "type_declaration"
-   in the remaining sentences, so that a private type (or private extension)
+   in the existing sentences, so that a private type (or private extension)
    can complete a type stub.
-
-   Add a new last sentence:
-        In the case of a type_stub, these checks are performed no later than
-        when a construct requires the completion to be available.
 
-Replace 3.10.1(5-10):
+Replace 3.10.1(5):
 
-        A name that denotes an incomplete_type_declaration may be used as
-        follows:
+   An incomplete_type_declaration defines an "incomplete view" of a type.
+   An incomplete view and the corresponding completing
+   type_declaration define two views of the same type.
 
-        * 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;
+   The only allowed uses of a name that denotes an incomplete view are
+   as follows:
 
-        * as the subtype_mark defining the subtype of a parameter or result of
-          an access_to_subprogram_definition;
+Replace 3.10.1(10):
 
-        * as the subtype_mark in an access_definition;
+        If a name that denotes an incomplete view is used in other
+        contexts, the complete view shall be *available* at the place of use,
+        as defined below:
 
-        A name that denotes an incomplete_type_declaration that includes the
-        keyword TAGGED may also be used as follows:
+           * If the incomplete view is declared by a type_stub, the complete
+             view is available if
 
-        * as the subtype_mark defining the subtype of a parameter in a
-          formal_part;
+              * the place of use of the name is within the immediate scope of
+		the completing type of the type_stub; or
 
-        * as the prefix of an attribute_reference whose attribute_designator is
-          Class; such an attribute_reference is restricted to the uses allowed
-          above.
+              * the place of use is within the scope of a with_clause that
+                mentions the unit [(including a library-level renaming)]
+                specified by the limited_unit_specifier of the type_stub.
 
-        If a name that denotes an incomplete_type_declaration is used in other
-        contexts, the incomplete_type_declaration shall be a type_stub, and the
-        completion shall be *available* at the place of use, as defined by
-        either of the following conditions:
+           * If the incomplete view is not declared by an
+             incomplete_type_declaration that is not a type_stub,
+             its complete view is available throughout the (extended) scope
+             of the completion.
 
-        * the place of use is within the immediate scope of the completion of
-          the type_stub; or
+           * If the incomplete view is a class-wide type, its complete view
+             is available if the complete view of the root of the class is
+             available.
 
-        * the place of use is within the scope of a with_clause that mentions
-          the package specified by the abstracted_package_specifier of the
-	  type_stub.
+        If the complete view of an incomplete view is available, the
+	complete view is used instead of the incomplete view.
 
-        The completion of an incomplete_type_declaration that is not a
-        type_stub is defined to be *available* throughout the (extended) scope
-        of the completion. The completion of an incomplete class-wide type is
-        *available* wherever the completion of the root of the class is
-        available.
-
         A dereference (implicit or explicit) of a value of an access type whose
-        designated type D is incomplete is allowed only in the following
-        contexts:
+        designated type D is an incomplete view is allowed only in the
+        following contexts:
 
-        * in a place where the completion of D is available (see above);
+        * in a place where the complete view of D is available (see above);
 
         * in a context where the expected type is E and
-           o E covers the completion of D,
+           o E covers the complete view of D,
            o E is tagged and covers D,
-           o E covers D'Class or its completion, or
-           o E'Class covers D or its completion;
+           o E covers D'Class or its complete view, or
+           o E'Class covers D or its complete view;
 
         * as the target of an assignment_statement where the type of the value
-          being assigned is V, and V or V'Class is the completion of D.
-
-        In these contexts, the incomplete type is defined to be the same
-        type as its completion, and its first subtype statically matches the
-        first subtype of its completion.
-
-Replace 3.10.1(11):
-
-        An incomplete_type_declaration declares an incomplete type and its
-        first subtype; the incomplete type is tagged if the keyword TAGGED
-        appears; the first subtype is unconstrained if a
-        known_discriminant_part appears. Two type_stubs are defined to be the
-        same type if they have the same defining identifier, the same sequence
-        of identifiers in their abstracted_package_specifiers, and their first
-        subtypes match statically.
+          being assigned is V, and V or V'Class is the complete view of D.
 
 Replace 10.01.2(3):
 
-	context_item ::= with_clause | use_clause | abstract_clause
+	context_item ::= with_clause | use_clause | limited_with_clause
 
 Add after 10.01.2(4):
 
-        abstract_clause ::= [private] ABSTRACT OF abstracted_package_specifier;
+        limited_with_clause ::= [PRIVATE] LIMITED WITH limited_unit_specifier;
 
 Add after 10.01.2(8):
 
-	The abstracted_package_specifier of an abstract_clause that appears on
+	The limited_unit_specifier of an limited_with_clause that appears on
 	a library_unit_declaration or library_unit_renaming_declaration may be
 	used in entire declarative region of the declaration, which includes
-	all children and subunits. The abstracted_package_specifier of an
-	abstract_clause that appears on a body may be used in that body,
+	all children and subunits. The limited_unit_specifier of an
+        limited_with_clause that appears on a body may be used in that body,
 	including all subunits.
 
-	A abstracted_package_specifier defined only in abstract_clauses that
+	A limited_unit_specifier defined only in abstract_clauses that
 	include the reserved word private shall be used only within
 	  * a private part,
 	  * a body,
 	  * a private descendant of the unit on which one of these
-	    abstract_clauses appear.
+	    limited_with_clauses appear.
 
-Add J.10:
+     Post-compilation rules
 
-   J.10 The Class Attribute of Non-tagged Incomplete Types
+	The limited_unit_specifier of a limited_with_clause shall specify the
+        full expanded name of a library compilation_unit (starting with a
+        root library unit, and using no renaming declarations). The unit that
+        includes the limited_with_clause in its context_clause shall
+        be included in the semantic closure of the unit specified by the
+        limited_unit_specifier.
 
+Add after 10.02(4):
+
+   * If a compilation unit is needed, then so are any compilation units
+     specified by the limited_unit_specifiers in limited_with_clauses of its
+     context_clause;
+
+Add J.11:
+
+   J.11 The Class Attribute of Non-tagged Incomplete Types
+
    For the first subtype S of a type T declared by an
    incomplete_type_declaration that is not tagged and is not a type stub, the
    following attribute is defined:
@@ -308,32 +271,32 @@
 it was more consistent to use the term "stub" rather than "separate"
 to be consistent with the program unit "stub" terminology.
 
-An abstract_clause does not declare a name. This was done so that we do not
+An limited_with_clause does not declare a name. This was done so that we do not
 have to introduce a "ghost" package in order to explain the presence of this
-name. We also do not want to be able to use the abstracted_package_specifier
+name. We also do not want to be able to use the limited_unit_specifier
 other than in a stub of some sort (with a type stub being the only kind allowed
 currently). If it is a name, it could be used in other contexts, requiring
 the insertion of checks that this is not the case into an implementation.
 
-We considered a syntax closer to that of existing with_clauses for
-abstract_clauses. For instance, we considered:
-    [private] separate with P;
-However, we rejected this for two reasons. First, this clause does not
-create a semantic dependence, while a with_clause does. It also does not
-declare a name. Thus it is very different semantically than a with_clause.
-Second, this syntax means that adding or removing a single keyword makes
-a massive semantic difference.
-
-We are not allowing an incomplete tagged type to be used as a
-return type, because of the many special rules and implementation issues
-associated with returning tagged types (e.g. functions that must be overridden,
-accessibility checks on returning limited by-reference types, dispatching on
-result coupled with tag indeterminacy, finalization associated with returning
-potentially controlled types, etc.).
-
-There may be multiple type stubs that are completed by a single
-completing type declaration. This is essential if type stubs are allowed in
-generic packages.
+We considered a variety of other syntaxes for limited_with_clauses. Several
+syntaxes that don't look like with_clauses. Since a limited_with_clause neither
+declares a name nor creates a semantic dependence, it doesn't seem that much
+like a with_clause. Thus, some reviewers preferred a different syntax. Two of
+the syntaxes
+considered were:
+    [private] abstract of P;
+which was rejected because describing the model it implied was very awkward,
+and
+    [private] use type in P;
+which was rejected because it is only one keyword different from "use type",
+and may cause confusion.
+
+We decided to stick with the familar with_clause syntax, as there are also
+similarities with regular with clauses:
+  -- The unit named is needed in the partition;
+  -- Dependencies between units are created.
+An alternative syntax using "separate" rather than "limited" was also considered,
+but that did not seem to have the correct connotation.
 
 There is no particular restriction on where a type stub may occur,
 unlike the restriction on program unit stubs. In particular, a type stub may
@@ -380,38 +343,104 @@
 it harder to share access types, and requiring trickier visibility rules to
 deal with "incomplete" packages as well as incomplete types.
 
+
+We introduce the idea of an "incomplete view" in this proposal. By so doing,
+we eliminate any need to talk about type matching, as there is only one type.
+Also note that we talk about a "completing type" for a type stub, rather than a
+completion. This avoids triggering the "hidden from all visibility" rules of
+8.3 on type stubs. We don't need these rules for type stubs, as it is not
+possible for the same name to denote both an incomplete view of a type stub and
+a complete view (the names are necessarily distinct). This property is not
+shared by any of the alternative proposals. Note that the "hidden from all
+visibility" rules cause significant problems with ripple effects (that is,
+indirect semantic dependence: cases where adding or deleting a context clause
+item from a distant unit changes the legality of some other compilation unit).
+
+Once we have the notion of an incomplete view, we could go further and make
+incomplete types first-class types, and thus allow the declaration of
+subtypes of them. This would be easy to do, but it doesn't seem to have any
+particular value. As unnecessary changes increase the risk of introducing
+errors, we did not make this change.
+
 Conceptual and implementation difficulties arise from the question where the
 type is to be regarded as completed and hence allows for object creation and
 availability of operations of the type. It is clear that such a place must have
-a semantic dependence on (the package containing) the type completion. However,
-to avoid ripple effects relating to "indirect" semantic dependences associated
-with "distant" with clauses, we propose that the completion is only "available"
-when within the immediate scope of the completion itself, or the scope of a
-with clause that mentions the completing package. This rule is relaxed when the
-complete type is in the immediate context of the usage (i.e., the incomplete
-type is used in a context where it must match the complete type).
+a semantic dependence on (the package containing) the completing type. However,
+to avoid ripple effects (see above), we say that the complete view is only
+"available" when within the immediate scope of the completing type itself, or
+the scope of a with clause that mentions the completing unit. This rule is
+relaxed when the completing type is in the immediate context of the usage
+(i.e., the incomplete view is used in a context where it matched the complete
+view).
 
 We considered other rules, such as requiring only semantic dependence (rejected
 due to the ripple effects), or creating an implicit semantic dependence at the
 point of a usage where the completion was needed (rejected due to difficulties
 for some implementations, and loss of visible "documentation" of the
 dependence).
+
+When the complete view of an incomplete view is available, the complete view
+is used in place of the incomplete view. This allows all of the operations of
+the complete view to work as expected. These rules have no effect on "old"
+incomplete types, as such incomplete views are always "hidden from all
+visibility". We considered modifying the "hidden from all visibility" rules
+to handle these cases as well, but the changes needed were substantial, and
+thus were likely to introduce errors into other parts of the language.
+
+
+This proposal includes post-compilation rules to insure that the completing
+type always has any type_stubs in its semantic closure. This makes type
+stubs slightly harder to use, but insures that we can perform all needed
+checking on the legality of the completing type when the completing unit is
+compiled. An additional rule insures that the completing type's unit must be
+included in the partition. Combined with the requirement that the completing
+type appear in the appropriate unit, we insure that all stubs are completed.
+
+In addition, we require that there is at most one stub for each completing type.
+This rule was originally adopted in order to eliminate the need for special
+type matching rules. However, with the adoption of the "incomplete view"
+model, we no longer need such rules anyway. We've retained the single stub
+requirement because it appears to make implementation easier for some
+implementation. [Note: An earlier draft of this AI said that allowing multiple
+stubs was necessary in order for type stubs to be usable with generics. If true,
+the rule should be removed.]
+
+The rule requiring that the completing type always has any type_stubs in its
+semantic closure could be accused of having a ripple effect. After all,
+removing a with_clause from some unit could make the partition illegal. We
+could have used wording requiring the with_clause directly on the unit
+referenced by the limited_with. However, note that it is the partition as a
+whole that is illegal, not any particular unit. The unit containing the
+completing type is perfectly legal as long as the unit with the type_stub and
+limited_with_clause isn't needed by the partition. Moreover, the binder error
+message for this error is likely to say "unit P needs a with_clause for unit Q
+as it has a limited_with_clause for P"; the user will simply add the needed
+clause and move on. As semantic closure is likely to be easier to check, we
+require the weaker condition.
+
+
+This proposal does not allowing type stubs to refer to local or nested
+completing types. This capability could be added by extending the syntax of
+type stubs to:
+   type_stub ::=
+       TYPE defining_identifier [discriminant_part] IS [ TAGGED ]
+            SEPARATE OF
+            [limited_unit_specifier .] {package_identifier .} type_identifier;
+and adding appropriate additional wording. If this is done, "old" incomplete
+types are usually just a shorthand for a type stub specifying the same unit.
+(If we allowed completions in private parts and bodies, this would be
+complete.)
+
+This was not done for multiple reasons. First, this syntax appears ambiguious
+(it is not possible to syntactically distiguish limited_unit_specifier from
+other identifiers). Second, the wording to describe the checks and meaning
+of this is complicated. Third, given that Ada includes child units, the
+nested unit containing a completing type can almost always be placed into a
+child unit, whereupon type_stubs as defined here can be used. Similarly,
+existing Ada facilities often can be used in that case, eliminating
+the need for stubs. Lastly, packages large enough to need this facility are
+quite rare.
 
-Another issue was whether the checking should happen at link time, or at any
-time when both the stub and the completing package were both in scope. We
-rejected both of these as they seemed to add complexity, without adding safety.
-Eliminating the link-time check was seen to be useful for testing individual
-subsystems, before an entire system was complete.
-
-We considered allowing the type stub to specify both the package where the
-completion occurs, and the name of the completing type. A potential syntax was
-"... is separate P.T" as an alternative to, or in addition to "... is separate
-in P". This seemed particularly useful in contexts where one wanted to have
-multiple type stubs in the same context, and type names like "Object" were
-being used consistently in packages. However, it was pointed out that the
-stubs could be placed in sub-packages if necessary to have two declared in the
-same context. This workaround was considered acceptable, and it preserved the
-simplicity of the single "separate in P" syntax.
 
 We considered having some restriction relating to specifying private child
 packages. However, it was unclear what the rule should be, and there seemed no
@@ -420,23 +449,16 @@
 the completion, and can dereference an access-to-type-stub. But there seems no
 particular harm in allowing the type stub to specify a private child. Without
 actually "looking" at the specified package, it may not be easy to determine
-whether it is a private child. If the check is made at the time of the use of
-the incomplete type, then a somewhat artificial check needs to be made at that
-time that the location of the type stub is inside the subsystem where the
-completing package is visible. An important property is that changing a
-private child, or adding or removing a private child, have no effect outside
-its "subsystem." That remains true even without any additional check, since
-the type stub by itself is legal, it is the usages that would be affected, and
-they would all have to be inside the subsystem.
-
-We considered limiting a package to a single abstract_clause. In this case,
-the abstract clause could be a modifier to the package rather than a
-context clause. This is closer to the intended use of the feature (creating
-an abstract for a single package). However, there seems to be no benefit
-for use or implementation to this restriction, and it is conceivable that
-valuable uses for packages containing multiple abstracted packages can be
-found.
+whether it is a private child. If the check is made when the stub is completed,
+then a somewhat artificial check needs to be made that the location of the type
+stub is inside the subsystem where the completing package is visible. An
+important property is that changing a private child, or adding or removing a
+private child, have no effect outside its "subsystem." That remains true even
+without any additional check, since the type stub by itself is legal, it is the
+usages that would be affected, and they would all have to be inside the
+subsystem.
 
+
 !example
 
 Here is the classic case of mutual dependence, where an employee
@@ -444,22 +466,22 @@
 is an employee. (We assume the use of tagged types here to illustrate the
 use of tagged incomplete types.)
 
-Two versions are presented. The first uses separate packages as package
-abstracts, which is usually advisable to have single well defined place
-for the access types. If it is desired to have the access type also be
-available in the abstracted package, that can be accomplished with a
-subtype declaration, as illustrated in package Employees.
+The example uses separate packages as package abstracts, which is usually
+advisable to have single well defined place for the access types. If it is
+desired to have the access type also be available in the completing package,
+that can be accomplished with a subtype declaration, as illustrated in package
+Employees.
 
 
-    abstract of Employees;
+    limited with Employees;
     package Employees_Abstract is
-        type Employee is tagged separate in Employees;
+        type Employee is tagged separate of Employees.Employee;
         type Emp_Ptr is access all Employee'Class;
     end Employees_Abstract;
 
-    abstract of Departments;
+    limited with Departments;
     package Departments_Abstract is
-        type Department is tagged separate in Departments;
+        type Department is tagged separate of Departments.Department;
         type Dept_Ptr is access all Department'Class;
     end Departments_Abstract;
 
@@ -468,7 +490,7 @@
         type Employee is tagged private;
         subtype Emp_Ptr is Employees_Abstract.Emp_Ptr;
         procedure Assign_Employee(E : in out Employee;
-                                  D : in out Departments_Abstract.Department);
+                                  D : in out Departments_Abstract.Department'Class);
         ...
         function Current_Department(D : in Employee) return
             Departments_Abstract.Dept_Ptr;
@@ -478,247 +500,224 @@
     package Departments is
         type Department is tagged private;
         procedure Choose_Manager(D : in out Department;
-                                 Manager : in out Employees_Abstract.Employee);
+                                 Manager : in out Employees_Abstract.Employee'Class);
         ...
     end Departments;
 
-The second version does a more direct coupling. (Note that,
-while it looks simpler and much more elegant, it can be used only in settings
-where the access types are needed in only one of the respective packages.)
-
-    abstract of Departments;
-    package Employees is
-        type Department is tagged separate in Departments;
-        type Dept_Ptr is access all Department'Class;
-        type Employee is tagged private;
-        procedure Assign_Employee(E : in out Employee;
-                                  D : in out Department);
-        ...
-        function Current_Department(D : in Employee) return Dept_Ptr;
-    end Employees;
 
-    abstract of Employees;
-    package Departments is
-        type Employee is tagged separate in Employees;
-        type Emp_Ptr is access all Employee'Class;
-        type Department is tagged private;
-        procedure Choose_Manager(D : in out Department;
-                                 Manager : in out Employee);
-        ...
-    end Departments;
-
-!corrigendum 3.10.1(2)
-
-@drepl
-@xindent<@fa<incomplete_type_declaration ::= @b<type> defining_identifier [discriminant_part];>>
-@dby
-@xindent<@fa<incomplete_type_declaration ::= @b<type> defining_identifier [discriminant_part] [@b<is tagged>];@hr
-     | type_stub>>
-
-@xindent<@fa<type_stub ::= @b<type> defining_identifier [discriminant_part] @b<is> [@b<tagged>]@hr
-     @b<separate in> abstracted_package_specifier;>>
-
-@xindent<@fa<abstracted_package_specifier ::= identifier |@hr
-     abstracted_package_specifier . identifier>>
-
-!corrigendum 3.10.1(3)
-
-@drepl
-An @fa<incomplete_type_declaration> requires a completion, which shall be a
-@fa<full_type_declaration>. If the @fa<incomplete_type_declaration> occurs
-immediately within either the visible part of a @fa<package_specification>
-or a @fa<declarative_part>, then the @fa<full_type_declaration> shall occur
-later and immediately within this visible part or @fa<declarative_part>. If
-the @fa<incomplete_type_declaration> occurs immediately within the private part
-of a given @fa<package_specification>, then the @fa<full_type_declaration>
-shall occur later and immediately within either the private part itself, or
-the @fa<declarative_part> of the corresponding @fa<package_body>.
-@dby
-An @fa<incomplete_type_declaration> other than a @fa<type_stub> requires a
-completion, which shall be a @fa<full_type_declaration>. If the
-@fa<incomplete_type_declaration> occurs immediately within either the visible
-part of a @fa<package_specification> or a @fa<declarative_part>, then the
-@fa<full_type_declaration> shall occur later and immediately within this
-visible part or @fa<declarative_part>. If the @fa<incomplete_type_declaration>
-occurs immediately within the private part of a given
-@fa<package_specification>, then the @fa<full_type_declaration> shall occur
-later and immediately within either the private part itself, or the
-@fa<declarative_part> of the corresponding @fa<package_body>.
-
-A @fa<type_stub> includes a @fa<abstracted_package_specifier> which specifies
-the full expanded name of the package in which its completion is expected to
-occur. Certain uses (see below) of a name that denotes the @fa<type_stub> or
-a value of an access type that designates the @fa<type_stub>, require that
-the completion exist. In these cases, the completion shall occur in the
-visible part of the specified package, and be a @fa<type_declaration> other
-than an @fa<incomplete_type_declaration>; the @fa<abstracted_package_specifier>
-shall be the full expanded name of this package (starting with a root
-library unit, and using no renaming declarations), and the package shall be
-a library package.
-
-!corrigendum 3.10.1(4)
-
-@drepl
-If an @fa<incomplete_type_declaration> has a @fa<known_discriminant_part>, then
-a @fa<full_type_declaration> that completes it shall have a fully conforming
-(explicit) @fa<known_discriminant_part> (see 6.3.1). If an
-@fa<incomplete_type_declaration> has no @fa<discriminant_part> (or an
-@fa<unknown_discriminant_part>), then a corresponding @fa<full_type_declaration>
-is nevertheless allowed to have discriminants, either explicitly, or inherited
-via derivation.
-@dby
-If an @fa<incomplete_type_declaration> includes the keyword @b<tagged>, then a
-@fa<type_declaration> that completes it shall declare a tagged type.
-If an @fa<incomplete_type_declaration> has a @fa<known_discriminant_part>, then
-a @fa<type_declaration> that completes it shall have a fully conforming
-(explicit) @fa<known_discriminant_part> (see 6.3.1). If an
-@fa<incomplete_type_declaration> has no @fa<discriminant_part> (or an
-@fa<unknown_discriminant_part>), then a corresponding @fa<type_declaration>
-is nevertheless allowed to have discriminants, either explicitly, or inherited
-via derivation. In the case of a @fa<type_stub>, these checks are performed no
-later than when a construct requires the completion to be available.
-
-
-!corrigendum 3.10.1(5)
-
-@drepl
-The only allowed uses of a name that denotes an @fa<incomplete_type_declaration>
-are as follows:
-@dby
-A name that denotes an @fa<incomplete_type_declaration> may be used as follows:
-
-!corrigendum 3.10.1(8)
-
-@drepl
-@xbullet<as the @fa<subtype_mark> in an @fa<access_definition>;>
-@dby
-@xbullet<as the @fa<subtype_mark> in an @fa<access_definition>.>
-
-A name that denotes an incomplete_type_declaration that includes the
-keyword @b<tagged> may also be used as follows:
-
-@xbullet<as the @fa<subtype_mark> defining the subtype of a parameter in a
-@fa<formal_part>;>
-
-
-!corrigendum 3.10.1(9)
-
-@drepl
-@xbullet<as the @fa<prefix> of an @fa<attribute_reference> whose
-@fa<attribute_designator> is Class; such an @fa<attribute_reference> is
-similarly restricted to the uses allowed here; when used in this way, the
-corresponding @fa<full_type_declaration> shall declare a tagged type, and the
-@fa<attribute_reference> shall occur in the same library unit as the
-@fa<incomplete_type_declaration>.>
-@dby
-@xbullet<as the @fa<prefix> of an @fa<attribute_reference> whose
-@fa<attribute_designator> is Class; such an @fa<attribute_reference> is
-restricted to the uses allowed above.>
-
-If a name that denotes an @fa<incomplete_type_declaration> is used in other
-contexts, the @fa<incomplete_type_declaration> shall be a @fa<type_stub>, and
-the completion shall be @i<available> at the place of use, as defined by
-either of the following conditions:
-
-@xbullet<the place of use is within the immediate scope of the completion of
-the @fa<type_stub>; or>
-
-@xbullet<the place of use is within the scope of a @fa<with_clause> that
-mentions the package specified by the @fa<abstracted package> of the
-@fa<type_stub>.>
-
-The completion of an @fa<incomplete_type_declaration> that is not a
-@fa<type_stub> is defined to be available throughout the (extended) scope
-of the completion. The completion of an incomplete class-wide type is
-available wherever the completion of the root of the class is available.
-
-!corrigendum 3.10.1(10)
-
-@drepl
-A dereference (whether implicit or explicit -- see 4.1) shall not be of an
-incomplete type.
-@dby
-A dereference (implicit or explicit -- see 4.1) of a value of an access type
-whose designated type @i<D> is incomplete is allowed only in the following
-contexts:
-
-@xbullet<in a place where the completion of @i<D> is available (see above);>
-
-@xbullet<in a context where the expected type is @i<E> and>
-@xinbull<@i<E> covers the completion of @i<D>,>
-@xinbull<@i<E> is tagged and covers @i<D>,>
-@xinbull<@i<E> covers @i<D>'Class or its completion, or>
-@xinbull<@i<E>'Class covers @i<D> or its completion;>
-
-@xbullet<as the target of an @fa<assignment_statement> where the type of the
-value being assigned is @i<V>, and @i<V> or @i<V>'Class is the completion of
-@i<D>.>
-
-In these contexts, the incomplete type is defined to be the same type as
-completion, and its first subtype statically matches the first
-subtype of its completion.
-
-!corrigendum 3.10.1(11)
-
-@drepl
-An @fa<incomplete_type_declaration> declares an incomplete type and its first
-subtype; the first subtype is unconstrained if a @fa<known_discriminant_part>
-appears.
-@dby
-An @fa<incomplete_type_declaration> declares an incomplete type and its
-first subtype; the incomplete type is tagged if the keyword @b<tagged>
-appears; the first subtype is unconstrained if a @fa<known_discriminant_part>
-appears. Two @fa<type_stub>s are defined to be the same type if they have the
-same defining identifier, the same sequence of identifiers in their
-@fa<abstracted_package_specifier>s, and their first subtypes match statically.
-
-!corrigendum 10.01.2(3)
-
-@drepl
-@xindent<@fa<context_item ::= with_clause | use_clause>>
-@dby
-@xindent<@fa<context_item ::= with_clause | use_clause | abstract_clause>>
-
-!corrigendum 10.01.2(4)
-
-@dinsa
-@xindent<@fa<with_clause ::= @b<with> @i<library_unit_>name {, @i<library_unit_>name }>>
-@dinst
-@xindent<@fa<abstract_clause ::= [@b<private>] @b<abstract of> abstracted_package_specifier;>>
-
-!corrigendum 10.01.2(8)
-
-@dinsa
-If a @fa<with_clause> of a given @fa<compilation_unit> mentions a private child
-of some library unit, then the given @fa<compilation_unit> shall be either the
-declaration of a private descendant of that library unit or the body or subunit
-of a (public or private) descendant of that library unit.
-@dinss
-The @fa<abstracted_package_specifier> of an @fa<abstract_clause> that appears on
-a @fa<library_unit_declaration> or @fa<library_unit_renaming_declaration> may be
-used in entire declarative region of the declaration, which includes
-all children and subunits. The @fa<abstracted_package_specifier> of an
-@fa<abstract_clause> that appears on a body may be used in that body,
-including all subunits.
-
-A @fa<abstracted_package_specifier> defined only in @fa<abstract_clause>s that
-include the reserved word @b<private> shall be used only within
-@xbullet<a private part,>
-@xbullet<a body,>
-@xbullet<a private descendant of the unit on which one of these
-@fa<abstract_clause>s appear.>
-
-!corrigendum J.10(1)
-
-@dinsc
-For the first subtype S of a type T declared by an
-@fa<incomplete_type_declaration> that is not tagged and is not a type stub, the
-following attribute is defined:
-
-@xhang<@xterm<S'Class>Denotes the first subtype of the incomplete class-wide
-type rooted at T. The completion of T shall declare a tagged type. Such an
-attribute reference shall occur in the same library unit as the
-@fa<incomplete_type_declaration>.
+--Note: Corrigendum sections not updated.
+--!corrigendum 3.10.1(2)
+--
+--@drepl
+--@xindent<@fa<incomplete_type_declaration ::= @b<type> defining_identifier [discriminant_part];>>
+--@dby
+--@xindent<@fa<incomplete_type_declaration ::= @b<type> defining_identifier [discriminant_part] [@b<is tagged>];@hr
+--     | type_stub>>
+--
+--@xindent<@fa<type_stub ::= @b<type> defining_identifier [discriminant_part] @b<is> [@b<tagged>]@hr
+--     @b<separate in> abstracted_package_specifier;>>
+--
+--@xindent<@fa<abstracted_package_specifier ::= identifier |@hr
+--     abstracted_package_specifier . identifier>>
+--
+--!corrigendum 3.10.1(3)
+--
+--@drepl
+--An @fa<incomplete_type_declaration> requires a completion, which shall be a
+--@fa<full_type_declaration>. If the @fa<incomplete_type_declaration> occurs
+--immediately within either the visible part of a @fa<package_specification>
+--or a @fa<declarative_part>, then the @fa<full_type_declaration> shall occur
+--later and immediately within this visible part or @fa<declarative_part>. If
+--the @fa<incomplete_type_declaration> occurs immediately within the private part
+--of a given @fa<package_specification>, then the @fa<full_type_declaration>
+--shall occur later and immediately within either the private part itself, or
+--the @fa<declarative_part> of the corresponding @fa<package_body>.
+--@dby
+--An @fa<incomplete_type_declaration> other than a @fa<type_stub> requires a
+--completion, which shall be a @fa<full_type_declaration>. If the
+--@fa<incomplete_type_declaration> occurs immediately within either the visible
+--part of a @fa<package_specification> or a @fa<declarative_part>, then the
+--@fa<full_type_declaration> shall occur later and immediately within this
+--visible part or @fa<declarative_part>. If the @fa<incomplete_type_declaration>
+--occurs immediately within the private part of a given
+--@fa<package_specification>, then the @fa<full_type_declaration> shall occur
+--later and immediately within either the private part itself, or the
+--@fa<declarative_part> of the corresponding @fa<package_body>.
+--
+--A @fa<type_stub> includes a @fa<abstracted_package_specifier> which specifies
+--the full expanded name of the package in which its completion is expected to
+--occur. Certain uses (see below) of a name that denotes the @fa<type_stub> or
+--a value of an access type that designates the @fa<type_stub>, require that
+--the completion exist. In these cases, the completion shall occur in the
+--visible part of the specified package, and be a @fa<type_declaration> other
+--than an @fa<incomplete_type_declaration>; the @fa<abstracted_package_specifier>
+--shall be the full expanded name of this package (starting with a root
+--library unit, and using no renaming declarations), and the package shall be
+--a library package.
+--
+--!corrigendum 3.10.1(4)
+--
+--@drepl
+--If an @fa<incomplete_type_declaration> has a @fa<known_discriminant_part>, then
+--a @fa<full_type_declaration> that completes it shall have a fully conforming
+--(explicit) @fa<known_discriminant_part> (see 6.3.1). If an
+--@fa<incomplete_type_declaration> has no @fa<discriminant_part> (or an
+--@fa<unknown_discriminant_part>), then a corresponding @fa<full_type_declaration>
+--is nevertheless allowed to have discriminants, either explicitly, or inherited
+--via derivation.
+--@dby
+--If an @fa<incomplete_type_declaration> includes the keyword @b<tagged>, then a
+--@fa<type_declaration> that completes it shall declare a tagged type.
+--If an @fa<incomplete_type_declaration> has a @fa<known_discriminant_part>, then
+--a @fa<type_declaration> that completes it shall have a fully conforming
+--(explicit) @fa<known_discriminant_part> (see 6.3.1). If an
+--@fa<incomplete_type_declaration> has no @fa<discriminant_part> (or an
+--@fa<unknown_discriminant_part>), then a corresponding @fa<type_declaration>
+--is nevertheless allowed to have discriminants, either explicitly, or inherited
+--via derivation. In the case of a @fa<type_stub>, these checks are performed no
+--later than when a construct requires the completion to be available.
+--
+--
+--!corrigendum 3.10.1(5)
+--
+--@drepl
+--The only allowed uses of a name that denotes an @fa<incomplete_type_declaration>
+--are as follows:
+--@dby
+--A name that denotes an @fa<incomplete_type_declaration> may be used as follows:
+--
+--!corrigendum 3.10.1(8)
+--
+--@drepl
+--@xbullet<as the @fa<subtype_mark> in an @fa<access_definition>;>
+--@dby
+--@xbullet<as the @fa<subtype_mark> in an @fa<access_definition>.>
+--
+--A name that denotes an incomplete_type_declaration that includes the
+--keyword @b<tagged> may also be used as follows:
+--
+--@xbullet<as the @fa<subtype_mark> defining the subtype of a parameter in a
+--@fa<formal_part>;>
+--
+--
+--!corrigendum 3.10.1(9)
+--
+--@drepl
+--@xbullet<as the @fa<prefix> of an @fa<attribute_reference> whose
+--@fa<attribute_designator> is Class; such an @fa<attribute_reference> is
+--similarly restricted to the uses allowed here; when used in this way, the
+--corresponding @fa<full_type_declaration> shall declare a tagged type, and the
+--@fa<attribute_reference> shall occur in the same library unit as the
+--@fa<incomplete_type_declaration>.>
+--@dby
+--@xbullet<as the @fa<prefix> of an @fa<attribute_reference> whose
+--@fa<attribute_designator> is Class; such an @fa<attribute_reference> is
+--restricted to the uses allowed above.>
+--
+--If a name that denotes an @fa<incomplete_type_declaration> is used in other
+--contexts, the @fa<incomplete_type_declaration> shall be a @fa<type_stub>, and
+--the completion shall be @i<available> at the place of use, as defined by
+--either of the following conditions:
+--
+--@xbullet<the place of use is within the immediate scope of the completion of
+--the @fa<type_stub>; or>
+--
+--@xbullet<the place of use is within the scope of a @fa<with_clause> that
+--mentions the package specified by the @fa<abstracted package> of the
+--@fa<type_stub>.>
+--
+--The completion of an @fa<incomplete_type_declaration> that is not a
+--@fa<type_stub> is defined to be available throughout the (extended) scope
+--of the completion. The completion of an incomplete class-wide type is
+--available wherever the completion of the root of the class is available.
+--
+--!corrigendum 3.10.1(10)
+--
+--@drepl
+--A dereference (whether implicit or explicit -- see 4.1) shall not be of an
+--incomplete type.
+--@dby
+--A dereference (implicit or explicit -- see 4.1) of a value of an access type
+--whose designated type @i<D> is incomplete is allowed only in the following
+--contexts:
+--
+--@xbullet<in a place where the completion of @i<D> is available (see above);>
+--
+--@xbullet<in a context where the expected type is @i<E> and>
+--@xinbull<@i<E> covers the completion of @i<D>,>
+--@xinbull<@i<E> is tagged and covers @i<D>,>
+--@xinbull<@i<E> covers @i<D>'Class or its completion, or>
+--@xinbull<@i<E>'Class covers @i<D> or its completion;>
+--
+--@xbullet<as the target of an @fa<assignment_statement> where the type of the
+--value being assigned is @i<V>, and @i<V> or @i<V>'Class is the completion of
+--@i<D>.>
+--
+--In these contexts, the incomplete type is defined to be the same type as
+--completion, and its first subtype statically matches the first
+--subtype of its completion.
+--
+--!corrigendum 3.10.1(11)
+--
+--@drepl
+--An @fa<incomplete_type_declaration> declares an incomplete type and its first
+--subtype; the first subtype is unconstrained if a @fa<known_discriminant_part>
+--appears.
+--@dby
+--An @fa<incomplete_type_declaration> declares an incomplete type and its
+--first subtype; the incomplete type is tagged if the keyword @b<tagged>
+--appears; the first subtype is unconstrained if a @fa<known_discriminant_part>
+--appears. Two @fa<type_stub>s are defined to be the same type if they have the
+--same defining identifier, the same sequence of identifiers in their
+--@fa<abstracted_package_specifier>s, and their first subtypes match statically.
+--
+--!corrigendum 10.01.2(3)
+--
+--@drepl
+--@xindent<@fa<context_item ::= with_clause | use_clause>>
+--@dby
+--@xindent<@fa<context_item ::= with_clause | use_clause | abstract_clause>>
+--
+--!corrigendum 10.01.2(4)
+--
+--@dinsa
+--@xindent<@fa<with_clause ::= @b<with> @i<library_unit_>name {, @i<library_unit_>name }>>
+--@dinst
+--@xindent<@fa<abstract_clause ::= [@b<private>] @b<abstract of> abstracted_package_specifier;>>
+--
+--!corrigendum 10.01.2(8)
+--
+--@dinsa
+--If a @fa<with_clause> of a given @fa<compilation_unit> mentions a private child
+--of some library unit, then the given @fa<compilation_unit> shall be either the
+--declaration of a private descendant of that library unit or the body or subunit
+--of a (public or private) descendant of that library unit.
+--@dinss
+--The @fa<abstracted_package_specifier> of an @fa<abstract_clause> that appears on
+--a @fa<library_unit_declaration> or @fa<library_unit_renaming_declaration> may be
+--used in entire declarative region of the declaration, which includes
+--all children and subunits. The @fa<abstracted_package_specifier> of an
+--@fa<abstract_clause> that appears on a body may be used in that body,
+--including all subunits.
+--
+--A @fa<abstracted_package_specifier> defined only in @fa<abstract_clause>s that
+--include the reserved word @b<private> shall be used only within
+--@xbullet<a private part,>
+--@xbullet<a body,>
+--@xbullet<a private descendant of the unit on which one of these
+--@fa<abstract_clause>s appear.>
+--
+--!corrigendum J.10(1)
+--
+--@dinsc
+--For the first subtype S of a type T declared by an
+--@fa<incomplete_type_declaration> that is not tagged and is not a type stub, the
+--following attribute is defined:
+--
+--@xhang<@xterm<S'Class>Denotes the first subtype of the incomplete class-wide
+--type rooted at T. The completion of T shall declare a tagged type. Such an
+--attribute reference shall occur in the same library unit as the
+--@fa<incomplete_type_declaration>.
 
 !ACATS test
 
@@ -1913,7 +1912,7 @@
 
 *************************************************************
 
-From: Randy Brukardt
+From: Gary Dismukes
 Sent: Wednesday, December 18, 2002 5:19 PM
 
 > I agree completely. Indeed, I was going to do just that if no one else beat

Questions? Ask the ACAA Technical Agent