CVS difference for ais/ai-30217.txt

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

--- ais/ai-30217.txt	2002/07/23 01:05:25	1.4
+++ ais/ai-30217.txt	2002/12/04 23:43:40	1.5
@@ -1,4 +1,4 @@
-!standard 03.10.01   (02)                           02-07-11  AI95-00217-04/03
+!standard 03.10.01   (02)                           02-12-02  AI95-00217-04/04
 !standard 03.10.01   (03)
 !standard 03.10.01   (04)
 !standard 03.10.01   (05)
@@ -14,17 +14,12 @@
 !status received 02-02-06
 !priority Medium
 !difficulty Hard
-!subject Handling mutually recursive types via type stubs with package specifiers
+!subject Type stubs with package specifiers
 
 !summary
 
-A new construct, called a "type stub," is proposed as a potential solution to
-the "mutually recursive types across packages" problem. This is an alternative
-to the "with type" proposal of AI-217-01, the "package abstract" proposal of
-AI-217-02, and the initial proposal for type stubs in AI-217-03.  [NOTE: the
-term "separate incomplete type" has been used instead of type stub, but we felt
-it was more consistent to use the term "stub" rather than "separate" to be
-consistent with the program unit "stub" terminology.]
+A new construct, called a "type stub," is added to the Standard to provide a
+solution to the "mutually recursive types across packages" problem.
 
 A type stub is a kind of incomplete type declaration which is completed in
 another (specified) package. The package in which the completion is to occur is
@@ -71,15 +66,16 @@
 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 an actual parameter that is a dereference of an
-access-to-tagged-incomplete value. The attribute 'Class is defined for
+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.) 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
+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.
 
-An additional kind of incomplete type declaration is proposed:
+A new kind of incomplete type declaration is added:
 
    type_stub ::=
        TYPE defining_identifier [discriminant_part]
@@ -107,7 +103,7 @@
 have the same 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 package specifier, and the other type
-can be a completion of the incomplete type.
+is an acceptable completion of the incomplete type.
 
 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
@@ -142,88 +138,86 @@
 Insert 3.10.1(3.1):
 
         A type_stub includes a 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 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 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.
+        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 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.
 
 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.
+        type_declaration that completes it shall declare a tagged type.
 
    Replace all occurrences of "full_type_declaration" with "type_declaration"
-   in the remaining sentences.
+   in the remaining 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.
+        when a construct requires the completion to be available.
 
 Replace 3.10.1(5-10):
 
         A name that denotes an incomplete_type_declaration may be used as
-	follows:
+        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;
+          access_to_object_definition; the only form of constraint allowed in
+          this subtype_indication is a discriminant_constraint;
 
         * as the subtype_mark defining the subtype of a parameter or result of
-	  an access_to_subprogram_definition;
+          an access_to_subprogram_definition;
 
         * as the subtype_mark in an access_definition;
 
         A name that denotes an incomplete_type_declaration that includes the
-	keyword TAGGED may also be used as follows:
+        keyword TAGGED may also be used as follows:
 
         * as the subtype_mark defining the subtype of a parameter in a
-	  formal_part;
+          formal_part;
 
         * as the prefix of an attribute_reference whose attribute_designator is
-	  Class; such an attribute_reference is restricted to the uses allowed
-	  above.
+          Class; such an attribute_reference is restricted to the uses allowed
+          above.
 
-[NOTE: The allowance for 'Class after a non-tagged incomplete type has been
-moved to Annex J. See below.]
-
         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:
+        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:
 
         * the place of use is within the immediate scope of the completion of
-	  the type_stub; or
+          the type_stub; or
 
         * the place of use is within the scope of a with_clause that mentions
-	  the package specified by the package_specifier of the type_stub.
+          the package specified by the package_specifier of the type_stub.
 
         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.
+        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 incomplete is allowed only in the following
+        contexts:
 
         * in a place where the completion 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 is tagged and covers 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;
 
         * 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.
+          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
@@ -232,12 +226,12 @@
 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 and same sequence
-        of identifiers in their package_specifiers; their first subtypes match
-	statically as well.
+        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 package_specifiers, and their first subtypes
+        match statically.
 
 Add J.10:
 
@@ -249,24 +243,28 @@
 
    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
-	incomplete_type_declaration.
+        T. The completion of T shall declare a tagged type. Such an attribute
+        reference shall occur in the same library unit as the
+        incomplete_type_declaration.
 
 !discussion
+
+We considered calling these "separate incomplete types", but we felt
+it was more consistent to use the term "stub" rather than "separate"
+to be consistent with the program unit "stub" terminology.
 
-Note that we are not proposing that an incomplete tagged type may be used as a
+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 becoming abstract,
+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.).
 
-Note that there may be multiple type stubs that are completed by a single
+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.
 
-Note that there is no particular restriction on where a type stub may occur,
+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
 occur in a declare block, a subprogram body, or anywhere an incomplete type
 declaration may occur. Of course, they are generally only useful if used in a
@@ -274,8 +272,8 @@
 completing package, so putting them in a declare block, or a subprogram body
 without any program unit stubs, would not be of any great use.
 
-There seem to be two general ways the problem of mutually recursive types is
-solved in other languages. One approach is to permit unrestricted forward
+There seem to be two general ways that the problem of mutually recursive types
+is solved in other languages. One approach is to permit unrestricted forward
 references. This is the approach adopted by Eiffel, Java, and Smalltalk.  The
 other approach is to require "forward" or "incomplete" declarations, sometimes
 called "signatures" or "partial revelations." This is generally the approach
@@ -311,7 +309,7 @@
 it harder to share access types, and requiring trickier visibility rules to
 deal with "incomplete" packages as well as incomplete types.
 
-Conceptual and implementation dificulties arise from the question where the
+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,
@@ -358,9 +356,7 @@
 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. Note that this decision is not
-critical either way. One could add the "artificial" check described above
-without otherwise altering the rest of the proposal.
+they would all have to be inside the subsystem.
 
 !example
 
@@ -369,7 +365,7 @@
 is an employee. (We assume the use of tagged types here to illustrate the
 use of tagged incomplete types.)
 
-Two versions are presented. One uses a separate interface package,
+Two versions are presented. One uses separate interface packages,
 possibly advisable to have single well defined place for the access
 types. The other does a more direct coupling. (Note that, while it
 looks simpler and much more elegant, it can be used only in settings
@@ -587,8 +583,8 @@
 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 and same sequence of identifiers in their
-@fa<package_specifiers>; their first subtypes match statically as well.
+same defining identifier, the same sequence of identifiers in their
+@fa<package_specifiers>, and their first subtypes match statically.
 
 !corrigendum J.10(1)
 

Questions? Ask the ACAA Technical Agent