CVS difference for ais/ai-60217.txt

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

--- ais/ai-60217.txt	2003/06/17 21:34:34	1.3
+++ ais/ai-60217.txt	2003/06/17 21:48:37	1.4
@@ -1,11 +1,12 @@
-!standard 03.10.01   (02)                           03-03-04  AI95-00217-07/01
+!standard 03.10.01   (02)                           03-05-16  AI95-00217-07/02
 !standard 03.10.01   (03)
 !standard 03.10.01   (11)
 !standard 08.03.00   (19)
+!standard 08.05.03   (04)
 !class amendment 03-03-03
 !status work item 03-03-03
 !status received 03-03-03
-!priority Medium
+!priority High
 !difficulty Hard
 !subject Incomplete type completed in a child
 
@@ -59,6 +60,42 @@
     incomplete_type_declaration  occurs immediately within ...
 	< rest remains the same >.
 
+Replace 3.10.1(10) with the following:
+
+	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:
+
+	* in a place where the completion of D is visible;
+
+	* 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 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.
+
+	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.
+
+Add after the above:
+
+            Post-Compilation Rules
+
+    If a package identifier is present in the declaration, and the
+    declaration occurs immediately within the visible or private part
+    of an enclosing package, and the named package is not itself declared
+    later and immediately within the same part of the enclosing package,
+    then the enclosing package shall be a library unit, and the named package
+    shall be a child of this library package (see 10.1.1).
+    Furthermore, if the incomplete type is declared in the visible part,
+    then the named package shall be a public child.  In either case, the
+    named child package is needed in a partition (see 10.2) that includes the
+    enclosing library package.
+
 Add the following sentences to the end of paragraph 3.10.1(11):
 
     If a package_identifier is present in the declaration, the
@@ -66,6 +103,21 @@
     region of the named package.  Otherwise, the incomplete type is
     declared immediately within the innermost enclosing declarative region.
 
+Add the following paragraph after 3.10.1(11):
+
+    If places where one or more incomplete_type_declarations are visible which
+    include the same package_identifier, a view of the named package
+    is visible with this identifier.  The view includes only the incomplete
+    types named in these incomplete_type_declarations.   [Note that in places
+    where the package_declaration or a library_unit_renaming_declaration for
+    this package is visible, all of the incomplete_type_declarations will
+    be hidden from all visibility.]
+  AARM only: Proof: 8.3(19) <as revised below> states that
+    a visible completion hides from all visibility the prior declaration.
+    8.5.3(4) <as revised below> indicates that the view provided by a library
+    item package renaming includes at least the entire visible part, meaning
+    that all of the completions will be visible.
+
 Change 8.3(19) as follows:
 
     If the completion of a declaration is a declaration, then [within
@@ -77,6 +129,33 @@
     or parameter_specification of a corresponding completion, or
     of a corresponding accept_statement {is visible}.
 
+Add the following after 8.5.3(4):
+
+    A view of a package can be visible due to any of the following kinds of
+    declarations being visible:
+
+	1) A package_declaration (see 7.1);
+	2) An incomplete_type_declaration that mentions a package (see 3.10.1);
+	3) A package_renaming_declaration that is a library item (see 10.1.1);
+	4) A package_renaming_declaration that is not a library item.
+
+    The view provided by a name that denotes a package_renaming_declaration
+    is determined by what if any other declarations are visible that provide
+    a view of the same package, as determined by the first of the following
+    that applies:
+
+        1) If the package_declaration itself is visible, then the view
+           provided is the same as that provided by a name that denotes
+           the package_declaration;
+        2) Otherwise, if only package_renaming_declarations
+           are visible, or if at least one of the renamings is a library item,
+           then the view provided is that of the visible part of the package,
+           augmented with whatever public children of the package have been
+           mentioned in with clauses that are in scope;
+        3) If neither of the above, then the view provided is that determined
+           by the set of incomplete_type_declarations that are visible and
+           that mention the package.
+
 !example
 
 (a) Here is the classic case of mutual dependence, where an employee
@@ -252,11 +331,19 @@
 scope of a library item extends to all its dependents, including
 those units that do not have "with" visibility on the _item.  But
 we have agreed in past discussions that we want the completing
-package (or a rename thereof) to be visible, not just somewhere
+package (or a library rename thereof) to be visible, not just somewhere
 within scope, if we are going to consider the type "completed."
 The new wording of the paragraph is intended to have no effect
 on existing code.
 
+Note the addition to 8.5.3.  We want non-library-unit renamings to
+provide the same view as whatever other view we already have of
+a package, whereas an explicit "with" of a library-unit renaming should
+always show at least the entire visible part.  We believe that this
+revision of the wording accomplishes this (albeit a bit wordily).
+Basically, we want one and only one view of a package at any given
+place, no matter what name is used to identify the package.
+
 One note about the syntax, to address Randy's concern.  Adding the
 optional "[package_identifer.]" to the syntax could be treated by the
 parser roughly in the same way as the optional "[parent_unit_name.]"
@@ -270,6 +357,7 @@
 package renaming as illustrated in the "package Forward" examples
 ((c) and (d)), it can accommodate use of the feature for packages that
 are not all part of a single package hierarchy.
+
 !ACATS test
 
 !appendix

Questions? Ask the ACAA Technical Agent