CVS difference for ais/ai-00326.txt

Differences between 1.6 and version 1.7
Log of other versions for file ais/ai-00326.txt

--- ais/ai-00326.txt	2003/09/19 01:42:28	1.6
+++ ais/ai-00326.txt	2003/11/27 02:01:16	1.7
@@ -1,4 +1,4 @@
-!standard 03.10.01   (02)                            03-09-18  AI95-00326/03
+!standard 03.10.01   (02)                            03-11-21  AI95-00326/04
 !standard 03.10.01   (04)
 !standard 03.10.01   (05)
 !standard 03.10.01   (08)
@@ -28,7 +28,7 @@
 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,
+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 parameters, since from a code generation
 point of view they are essentially equivalent to access parameters.
@@ -44,63 +44,198 @@
 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 a dereference of an access to tagged incomplete
-can be used as an actual parameter for a class-wide tagged incomplete formal
-parameter. 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.
+can be used as an actual parameter. 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.
 
 
 !wording
 
+Note: This wording includes the changes needed to support AI-217-6. These rules
+are marked.
+
+Replace 3.2(4) by:
+
+  The composite types are the record types, record extensions, array types,
+  task types, and protected types.
+
+  There can be multiple views of a type with varying sets of operations. An
+  incomplete type represents an incomplete view (see 3.10.1) of a type with a
+  very restricted usage, providing support for recursive data structures. A
+  private type or private extension represents a partial view (see 7.3) of a
+  type, providing support for data abstraction. The full view (see 3.2.1) of a
+  type provides its complete declaration. An incomplete or partial view is a
+  composite type.
+
+AARM: Only the first and last sentences really define anything; the real
+  definitions of the views are in the referenced paragraphs.
+
+Modify 3.2(5):
+
+  Certain composite types (and [partial] views thereof) have special...
+
+Add to 3.2.1(8) before the last sentence:
+
+  A full type defines the full view of a type.
+
+AARM Change: All types have full views in this model. The penultimate sentence
+  of 7.3(4) gets square brackets in the RM (but I'd recommend leaving it there
+  in order to keep the entire private type model intact).
+
+Modify 3.7(1) to remove the two occurrences of "partial" in the second sentence.
+
+Note: Incomplete views can have unknown_discriminant_parts, and this wording
+  should reflect that. Since full views cannot have unknown_discriminant_parts,
+  "view of a type" is enough here.
+
+Modify 3.9.2(2):
+
+  Add the the end of the second sentence:
+
+  controlling formal parameter{, and the type T is called the controlling type}.
+
+Add after 3.9.2(8):
+
+  The view of the controlling type of a dispatching call shall not be an
+  incomplete view.
+
+AARM Note: This prevents dispatching when the position of the tag may not be
+  known, and fixes a hole in Ada 95. (Then give the example from the
+  !discussion section below.)
+
 Replace 3.10.1(2):
 
    incomplete_type_declaration ::=
       TYPE defining_identifier [discriminant_part] [IS TAGGED];
 
-Modify 3.10.1(4):
+Modify 3.10.1(3):
 
-   Add a new first sentence:
+Replace the first sentence by:
 
-        If an incomplete_type_declaration includes the keyword TAGGED, then a
-        type_declaration that completes it shall declare a tagged type.
+  An incomplete_type_declaration declares an incomplete view of the type; such
+  a declaration requires a completion, which shall be a type_declaration other
+  than an incomplete_type_declaration.
 
-Replace 3.10.1(5-9):
+In the other sentences, replace "full_type_declaration" with "type_declaration".
+
+AARM Changes: We define "incomplete view" here. Completions can now be private
+  types. That means that the completing view can be either a partial view or a
+  full view.
 
-        A name that denotes an incomplete_type_declaration may be used as
-        follows:
+Modify 3.10.1(4):
+
+Add two new first sentences:
 
-        * 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;
+  If an incomplete_type_declaration includes the keyword TAGGED, then the
+  type_declaration that completes it shall declare a tagged type. Such an
+  an incomplete_type_declaration declares a tagged incomplete view.
 
-        * as the subtype_mark defining the subtype of a parameter or result of
-          an access_to_subprogram_definition;
+In the other sentences, replace "full_type_declaration" with "type_declaration".
+
+Replace 3.10.1(5-9):
 
-        * as the subtype_mark in an access_definition;
+  The only allowed uses of a name that denotes an incomplete view are as
+  follows:
 
-        A name that denotes an incomplete_type_declaration that includes the
-        keyword TAGGED may also 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;
 
-        * as the subtype_mark defining the subtype of a parameter in a
-          formal_part;
+    * as the subtype_mark defining the subtype of a parameter or result of
+      an access_to_subprogram_definition;
 
-        * as the prefix of an attribute_reference whose attribute_designator is
-          Class; such an attribute_reference is restricted to the uses allowed
-          above.
+    * as the subtype_mark in an access_definition;
 
-Replace 3.10.1(10):
+  In addition, a tagged incomplete view may be used as follows:
 
-        An incomplete_type_declaration declares an incomplete type and its
+    * as the subtype_mark defining the subtype of a parameter in a
+      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 for tagged incomplete views.
+
 Replace 3.10.1(11):
 
-        A dereference (whether implicit or explicit -- see 4.1) shall not be
-        of an incomplete type, unless it is directly used as an actual
-        parameter where the expected type is a class-wide tagged incomplete
-        type.
+  A subtype_mark that denotes an incomplete_type_declaration for a type T
+  provides an incomplete view of T except when:
+    * it occurs in the immediate scope of the completion of T, or
+    * it occurs in the scope of a nonlimited_with_clause that mentions
+      the library package in which the completion of T is declared, where not
+      within the immediate scope of the incomplete_type_declaration of T.
+
+AARM Note: We need the "where not within in the immediate scope" rule so that
+  the second rule doesn't trigger in the body of a package with a with of a
+  child unit:
+
+   package P is
+   private
+      type T;
+      type AT is access T;
+   end P;
+
+   private package P.C is
+      P : AT;
+   end P.C;
+
+   with P.C;
+   package body P is
+       -- P.all is not legal here, but it is in the scope of a non-limited
+       -- with_clause for P.
+       type T is ...
+       -- P.all is legal here.
+   end P;
+
+AI-217 Note: The above rules comes from AI-217-06. Note that here we say that
+  the view is complete, and thus none of the restrictions outlined in this
+  section apply, not just dereferencing as the AI-217-6 wording said. I believe
+  that is what was intended (it certainly is what *I* thought was intended).
+
+  A dereference (whether implicit or explicit -- see 4.1) shall not be
+  of an incomplete view, unless:
+    * its expected type is not an incomplete view of T;
+
+AARM Note: This means that it is a partial or full view of T. We don't
+enumerate the kinds of views to make it easier to add other kinds of views in
+the future.
+
+AI-217 Note: This also comes from AI-217.
+
+    * it is a tagged incomplete view and it is used as an actual parameter of a
+      call, or the expression of a qualified_expression or parenthesized
+      expression used in one of these contexts.
+
+AARM Note: Dispatching calls are prohibited for incomplete views (see 3.9.2),
+so this is mainly useful in class-wide calls.
+
+AARM To Be Honest: This really means "top-level" actual parameter with arbitrary
+qualified_expressions and parents. We can't allow it to occur as the operand
+of a type conversion, membership operation, or predefined equality. Since
+equality is a function, it is already covered by these rules, but the other
+cases aren't.
+
+*** Open issue: Alternative wording could say "...it is used in the expression
+or name of an actual parameter of a call, but not as the operand of a type
+conversion or membership operation." But that brings up the possibility of
+missing a problem case.
+
+4.1(9): No change is needed. Note that this differs from the proposed AI-217-6.
+
+Modify 13.1(11/1):
+
+  Replace the second sentence by:
+
+   Operational and representational aspects are the same for all views of
+   a type.
+
+Note: This change isn't strictly necessary; you can't actually tell those
+aspects for an incomplete view. But it is an important part of the "view of
+a type" model. We could add a clarification like "Thus, the aspects of an
+incomplete or partial view are the same as those of the full view of the type."
 
 Add J.11:
 
@@ -116,15 +251,14 @@
         reference shall occur in the same library unit as the
         incomplete_type_declaration.
 
+
 !discussion
 
-Tagged type hierarchies often have need for mutually
-dependent types.  By allowing a tagged incomplete type
-to be used as a formal parameter type, access parameters
-may be avoided in such mutually dependent type situations.
-This proposal gains additional power when combined with
-the proposals for allowing mutually dependent types to
-be defined in separate packages.
+Tagged type hierarchies often have need for mutually dependent types. By
+allowing a tagged incomplete type to be used as a formal parameter type, access
+parameters may be avoided in such mutually dependent type situations. This
+proposal gains additional power when combined with the proposals for allowing
+mutually dependent types to be defined in separate packages.
 
 We are not allowing an incomplete tagged type to be used as a
 return type, because of the many special rules and implementation issues
@@ -134,137 +268,177 @@
 result coupled with tag indeterminacy, finalization associated with returning
 potentially controlled types, etc.).
 
-Similarly, we are not allowing an incomplete tagged type to be dereferenced
-(and thus used as an actual parameter) in most cases, because doing so may
-require the reading of the tag and/or discriminants, whose positions are not
-known. However, we are allowing such a use as an actual parameter of a
-class-wide tagged incomplete type, as such objects are passed by reference
-with no need to read any portion of them.
+3.2.1(8) is the only place where an incomplete type is described as a "view".
+Elsewhere in the standard, it is described as a separate type. However, the
+separate type model has a number of bad effects (for instance, nowhere in the
+standard does it say that an incomplete type matches its completing type - if
+the types are different, that's necessary). Moreover, private types are
+described in the standard as a partial view of a type. An incomplete type is
+just another kind of restricted view, so it is very strange that the
+description is completely different. In addition, incomplete types are omitted
+from various text in the standard; if they're separate types, there would be
+quite a bit of patching to do.
+
+Thus, the wording generalizes the concept "view of a type" to encompass
+incomplete views as well as partial views. We considered generalizing the
+concept of a "partial view of a type" instead. However, that led to lengthy
+terms for specific kinds of partial views: "tagged incomplete partial view"
+and "limited private partial view" are just too unwieldy.
 
-For instance:
+A possible hole was discovered during this discussion:
 
-      package Typ is
-          type T is tagged;
-          type AT is access all T;
-          procedure Op1 (Obj : in out T'Class);
-          procedure Op2 (Obj : in out T);
-          ...
-      end Typ;
+    package P is
+      ...
+    private
+      type T1;
+      type AT1 is access all T1'Class;
+      P1 : AT1;
+      type T2 is tagged;
+      type AT2 is access all T2'Class;
+      P2 : AT2;
+    end P;
+
+    private package P.C is
+      procedure Foo (P : access T1);
+      procedure Bar (P : T2);
+      procedure Test;
+    end P.C;
+
+    package body P.C is
+      procedure Test is
+      begin
+        Foo (P.P1); -- A dispatching call! (Ada 95)
+        Bar (P.P2.all); -- A dispatching call! (Ada 0Y)
+      end Test;
+    end P.C;
+
+If the body of P sets P1 and P2 to objects, the calls to Foo and Bar are
+dispatching calls and logically ought to work. But the location of the
+tags for T1 and T2 are unknown when the calls are compiled. Therefore, we
+add a rule to make dispatching calls when the dispatching type is incomplete
+illegal.
 
-      with Typ;
-      procedure User is
-          ...
-          P : Typ.AT := ...;
-          ...
-          Typ.Op1 (P.all); -- OK.
-          Typ.Op2 (P.all); -- Can't allow (don't know where the tag is).
-          ...
-      end User;
+Dereferences of incomplete tagged types are still be useful for class-wide
+calls. For instance (presuming AI-217-6 is approved):
 
-Note that Op1 could be used as a work-around to implement Op2 if that was
-necessary (as the body of Typ.Op1 certainly could dispatch to Op2; it can
-see the completing type).
+    limited with Departments;
+    package Employees is
+       type Employee is private;
+       procedure Assign (E : Employee; D : Departments.Department'Class);
+       type Dept_Ptr is access Departments.Department'Class;
+    end Employees;
 
+    with Employees;
+    procedure Recruit (D : Employees.Dept_Ptr; E : Employees.Employee) is
+    begin
+       Employees.Assign (E, D.all);
+    end Recruit;
 
-!example
+From the perspective of Recruit, a Departments.Department is just a black box
+that Employees uses and it was passed and is passing along. It would be bizarre
+for Recruit to have to with Departments simply to be able to call Assign.
 
-!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>];
-
-!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.
-
-!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.>
-
-!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 (whether implicit or explicit -- see 4.1) shall not be
-of an incomplete type, unless it is directly used as an actual
-parameter where the expected type is a class-wide tagged incomplete type.
-
-!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.
-
-!corrigendum J.11(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>.
+!example
 
+--*** Will redo the !corrigendum in the future.
+--!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>];
+--
+--!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.
+--
+--!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.>
+--
+--!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 (whether implicit or explicit -- see 4.1) shall not be
+--of an incomplete type, unless it is directly used as an actual
+--parameter where the expected type is a class-wide tagged incomplete type.
+--
+--!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.
+--
+--!corrigendum J.11(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
 
 ACATS B and C tests should be constructed for this AI.
@@ -604,6 +778,103 @@
 Now, we all *know* this works. The question is merely where does the RM say
 that. If it doesn't, of course, we have another hole to fix, which should be
 taken into account when writing the wording.
+
+*************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, November 20, 2003, 11:20 PM
+
+Following is an analysis of the RM wrt to making an incomplete view a
+type of partial view. Various uses of "partial view" would need to be
+qualified with "private".
+
+Appendix: All references to "incomplete type" in the AARM other than 3.10.1.
+
+3.1(12.i): informal use.
+3.2.1(26.c): informal use.
+3.9(15.c): informal use.
+7.1(17.c): Applies to type decl, no changes needed.
+13.14(1.j): informal use.
+13.14(3/1): Applies to type decl, no changes needed.
+13.14(3.b): informal use.
+B.1(26.b): Applies to type decl, no changes needed.
+
+---
+
+Appendix: All references to "partial view" in the AARM.
+
+3.7(1): use of unknown discriminants. OK unchanged. (3.10.1 definitely allows
+  unknown_discriminants on incomplete types; but it is not clear that this rule
+  does.)
+3.7(26.c): Same as above.
+13.1(11/1): Same rep. for both views. Harmless to say (even though you can't
+  query those aspects).
+8.3(10.b): An AARM note, and appears true. This is discussing primitive
+  operations. It appears that incomplete types have primitive operations by
+  3.2.3(6), so the note seems to be true.
+     package Foo is
+         ...
+     private
+         type Arg;
+         procedure Goody (P : access Arg); -- Primitive for Arg.
+     end Foo;
+7.5(1.c): An AARM note (about limited types completed by non-limited types).
+  Probably fine as is (and probably wrong because of AI-287 anyway).
+3.9.3(9): Says that the full view of a non-abstract partial view must not be
+  abstract. Seems to need change (can an incomplete type be completed by an
+  abstract type? I think so.)
+3.9.2(12.a.1/1): An AARM note that says that the rule against multiple
+  dispatching applies to full views. (This was a ramification published in the
+  defect reports.) Does this apply to incomplete types? Looks ugly either way:
+     package Foo2 is
+         ...
+     private
+         type Arg2;
+         type Arg3;
+         procedure Yikes (P : access Arg2; P2 : access Arg3);
+     end Foo2;
+     package body Foo2 is
+         type Arg2 is tagged...
+         type Arg3 is tagged...
+         ...
+     end Foo2;
+  Is Yikes illegal? Where is the check made? Of course, if these were a tagged
+  incomplete types it would be easier to check. So I think that this note is
+  correct, and should stand, even for incomplete partial views.
+3.9(2): Discusses a particular kind of partial view. No change needed.
+3.4(24): Discusses more particular kinds of partial view. No change needed.
+7.3.1(10-13): These notes describe operations of private partial views. They'd
+  need to be qualified. But they're notes - no big deal.
+3.2(2.p): Defines the glossary entry for "private type". Its "A partial view",
+  it isn't exclusive.
+3.2(4): A private type represents a partial view. No problem. Also, a partial
+  view is composite. Humm. I don't think that is a problem, either, given how
+  little can be done with an incomplete view.
+3.2(5): Partial views may have discriminants. That's fine. Indeed, it looks
+  like incomplete types were completely omitted from this section, which seems
+  a bit weird. They're not that different from private types.
+7.3(4): A private type declares a partial view. That probably would be OK
+  without change, but it would be a bit confusing. Also, we would probably want
+  to introduce the qualifier "private" here. The part about a partial view
+  requiring a completion would have to change to "private partial view".
+7.3(5): This is bracketed in the AARM to mean "redundant". It's also true of
+  incomplete types - but a bit confusing.
+7.3(6): This would have to be qualified as "private partial view" (no such
+  thing as a limited incomplete type, nor are there any restrictions on
+  completion).
+7.3(7): The third sentence would have to be qualified. As would the following
+  AARM notes (which I won't list here).
+7.3(9): Incomplete types have the same rule; we could get rid of one of the
+  copies.
+7.3(10.a): AARM note, which is OK.
+7.3(11): This already applies to incomplete types. Another rule we could get
+  rid of.
+7.3(12): Applies only to private types, would have to be qualified.
+7.3(15): The first sentence applies to both; the rest (which probably ought
+  to be split out) only apply to private types.
+7.3(17): Specific uses of partial view; no change would be required.
+7.3(18): Specific use of partial view; no change would be needed.
+3.2.1(8): "partial and incomplete view". Humm.
 
 *************************************************************
 

Questions? Ask the ACAA Technical Agent