CVS difference for ais/ai-00262.txt

Differences between 1.11 and version 1.12
Log of other versions for file ais/ai-00262.txt

--- ais/ai-00262.txt	2002/06/11 05:15:49	1.11
+++ ais/ai-00262.txt	2002/06/14 23:48:56	1.12
@@ -67,14 +67,14 @@
 
 Add after 10.1.2(8):
 
-A name shall not denote a declaration mentioned only in a with_clause which
-includes the reserved word private if:
-    * the name appears in the visible part of a package or generic package, or
-    * the name appears in a use_clause in a context_clause.
+A name denoting a declaration mentioned only in a with_clause which
+includes the reserved word private shall appear only in a context_clause,
+body, private part of a package or generic package, or private descendant of
+the unit on which the with_clause appears. Such a name shall not appear in
+a use_clause in a context_clause.
 
 A with_clause which includes the reserved word private shall appear only
-in the context_clause of a package specification or generic package
-specification.
+in the context_clause of a package_declaration or generic_package_declaration.
 
 !discussion
 
@@ -212,17 +212,17 @@
 @xbullet<the body or subunit of a (public or private) descendant of that
 library unit; or>
 @xbullet<the declaration of a public descendant of that library unit, and
-the @fa<with_clause> shall include the reserved word @b<private>.>
+the @fa<with_clause> shall include the reserved keyword @b<private>.>
 
-A @fa<name> shall not denote a declaration mentioned only in a
-@fa<with_clause> which includes the reserved word @b<private> if:
-@xbullet<the @fa<name> appears in the visible part of a package or generic
-package, or>
-@xbullet<the name appears in a @fa<use_clause> in a @fa<context_clause>.>
-
-A @fa<with_clause> which includes the reserved word @b<private> shall appear
-only in the @fa<context_clause> of a package specification or generic package
-specification.
+A @fa<name> denoting a declaration mentioned only in a @fa<with_clause> which
+includes the reserved keyword @b<private> shall appear only in a
+@fa<context_clause>, @fa<body>, private part of a package or generic package,
+or private descendant of the unit on which the @fa<with_clause> appears. Such a
+@fa<name> shall not appear in a @fa<use_clause> in a @fa<context_clause>.
+
+A @fa<with_clause> which includes the reserved keyword @b<private> shall appear
+only in the @fa<context_clause> of a @fa<package_declaration> or
+@fa<generic_package_declaration>.
 
 !ACATS test
 
@@ -2794,5 +2794,267 @@
 "private with" syntax by which context clauses that are needed only by the
 private part of a package can be differentiated from context clauses that
 are needed by the visible part (or both parts).
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Wednesday, May 22, 2002  8:32 PM
+
+Baird, Steve wrote:
+
+>1) Does AI-262 (private withs) result in the following
+>   program being incorrectly accepted?
+>
+>     package Pkg is
+>     end Pkg;
+>
+>     private procedure Pkg.Proc;
+>
+>     private with Pkg.Proc;
+>     package Pkg.Child is
+>       generic
+>         with procedure Proc is <>;
+>       package G is
+>       end G;
+>
+>       package I is new G;
+>     end Pkg.Child;
+>
+>   Clearly Pkg.Child would be rejected if the instantiation's
+>   parameter were specified explicitly, but does the wording
+>   of the AI cover the defaulted case?
+>
+
+I don't see a problem here.  This is a case where the use of an equivalence
+rule saves us (now that's unusual ;-).  12.6(10) says that omitting an
+actual subprogram when the default is a box is equivalent to an
+explicit actual parameter that is a usage name identical to the
+defining name of the formal.
+
+On the other hand, now that I look more closely at the suggested wording
+that is to follow 10.1.2(8), it seems like it has a fundamental problem.
+Here is the wording, to remind people:
+
+>A name shall not denote a declaration mentioned only in a with_clause which
+>includes the reserved word private if:
+>    * the name appears in the visible part of a package or generic package, or
+>    * the name appears in a use_clause in a context_clause.
+
+
+This talks about the visible part of *a* package.  That seems overly
+general.  If a subpackage is entirely located within the private part,
+then it should be OK to denote a privately-withed unit.  I can imagine
+at least two more reasonable rules:  One is that a name denoting a
+privately-withed unit shall not appear within the visible part of
+*the* compilation unit.  Alternatively, such a name is allowed only
+within the private part, body, or descendant of a unit within the scope
+of the private with clause.
+
+The latter rule allows uses within the private part of visible
+sub-packages, which seems to have been the intent of the original
+wording.  The latter rule would benefit from the definition of the notion
+of a "visible place," as opposed to simply a "visible part of an entity"
+which is what 8.2 defines, or the visibility of a declaration which
+is what 8.3 defines.  Note that AI-195 would also benefit from
+the definition of a "visible place."  An attribute definition would
+be "available" if it appeared in a "visible place."
+
+So let me formally suggest we define what it means for a "place"
+to be visible, and then we could say that a reference to a privately-withed
+unit would not be legal in a place that is visible outside the
+declarative region of the library package or generic library package.
+Similar wording could be used in AI-195, rather than the awkward
+wording saying an attribute definition is available if it is
+in a place where a declaration would have been visible.
+
+Clearly once we have the definition for a "visible place," we can
+use it for attribute definitions, pragmas, declarations, and
+references.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Wednesday, June 12, 2002  9:04 PM
+
+Tucker wrote (a long time ago):
+
+> On the other hand, now that I look more closely at the uggested wording
+> that is to follow 10.1.2(8), it seems like it has a fundamental problem.
+> Here is the wording, to remind people:
+>
+> >A name shall not denote a declaration mentioned only in a with_clause which
+> >includes the reserved word private if:
+> >    * the name appears in the visible part of a package or generic
+> >         package, or
+> >    * the name appears in a use_clause in a context_clause.
+> >
+>
+> This talks about the visible part of *a* package.  That seems overly
+> general.  If a subpackage is entirely located within the private part,
+> then it should be OK to denote a privately-withed unit.  I can imagine
+> at least two more reasonable rules:  One is that a name denoting a
+> privately-withed unit shall not appear within the visible part of
+> *the* compilation unit.  Alternatively, such a name is allowed only
+> within the private part, body, or descendant of a unit within
+> the scope of the private with clause.
+>
+> The latter rule allows uses within the private part of visible
+> sub-packages, which seems to have been the intent of the original
+> wording.
+
+Please do not assume the intent of the author. The author does not claim to
+have thought about nested packages. :-)
+
+> The latter rule would benefit from the definition of the notion
+> of a "visible place," as opposed to simply a "visible part of an entity"
+> which is what 8.2 defines, or the visibility of a declaration which
+> is what 8.3 defines.  Note that AI-195 would also benefit from
+> the definition of a "visible place."  An attribute definition would
+> be "available" if it appeared in a "visible place."
+>
+> So let me formally suggest we define what it means for a "place"
+> to be visible, and then we could say that a reference to a privately-withed
+> unit would not be legal in a place that is visible outside the
+> declarative region of the library package or generic library package.
+> Similar wording could be used in AI-195, rather than the awkward
+> wording saying an attribute definition is available if it is
+> in a place where a declaration would have been visible.
+>
+> Clearly once we have the definition for a "visible place," we can
+> use it for attribute definitions, pragmas, declarations, and
+> references.
+
+This latter proposal seems too complex to me.
+
+However, Tucker is thinking too much about nested packages, and forgot about
+children. It is important the rule applies to any children which inherit the
+private with. (I was thinking about children, and forgot about nested
+packages. So I guess we're even.)
+
+Anyway, to clarify the issue, and to work through to a solution, consider
+the following program:
+
+    private with Priv;
+    package Pack is
+        A : Integer := Priv.Int; -- Error.
+        package Nest is
+            B : Integer := Priv.Int; -- Error.
+        private
+            C : Integer := Priv.Int; -- ??.
+        end Nest;
+    private
+        D : Integer := Priv.Int; -- OK.
+        package Nesting is
+            E : Integer := Priv.Int; -- ??.
+        private
+            F : Integer := Priv.Int; -- OK.
+        end Nesting;
+    end Pack;
+
+    package Pack.Child is -- Inherits the private with.
+        G : Integer := Priv.Int; -- Better be illegal!
+    private
+        H : Integer := Priv.Int; -- OK.
+    end Pack.Child;
+
+It is clear that A and B must be illegal, and D and F must be legal, in
+order for "private with" to make any sense. The question is whether C and E
+ought to be legal. Similarly, in the child, G must be illegal, and H must be
+legal.
+
+The existing rule:
+  A name shall not denote a declaration mentioned only in a with_clause which
+  includes the reserved word private if:
+     * the name appears in the visible part of a package or generic
+         package, or
+     * the name appears in a use_clause in a context_clause.
+
+makes both C and E illegal, because both appear in the visible part of some
+package. In both cases, the items are also in a private part, but that isn't
+relevant.
+
+A simple alternative is:
+
+  A name shall not denote a declaration mentioned only in a with_clause which
+  includes the reserved word private if:
+     * the name appears in the visible part of the package or generic
+         package on which the with_clause appears, or
+     * the name appears in a use_clause in a context_clause.
+
+This makes E legal, but not C. That is OK (I wonder if C could be
+re-exported later in the visible part of Pack anyway). But this rule has a
+fatal flaw: it makes G legal, which we clearly do not want.
+
+We could complicate the rule further by including children explicitly, but
+this does not look appealing.
+
+After all, the best reason for making C legal is that if Nest was extracted
+and turned into a child package, C would be legal. This seems like the
+preferred property (assuming that there isn't a way to re-export the private
+information).
+
+Tucker then goes on to propose (OK, I'm writing the wording for him):
+
+  A name denoting a declaration mentioned only in a with_clause which
+  includes the reserved word private shall appear only in the context_clauses,
+  private part, body, or descendants of the package or generic package on which
+  the with_clause appears. Such a name shall not appear in a use_clause in a
+  context_clause.
+
+(I added "context_clause" here, so that the intended uses of the name for
+further private withs and in Elaborate pragmas are allowed).
+
+This makes C illegal (because a nested package is not a descendant) and E is
+legal (because it is in the private part. However, G is now legal (because
+Pack.Child is a descendant of the package), so this wording does not work.
+
+To fix these problems, we need to make two changes to this wording. First,
+we need to avoid specifying which package. Any package in the scope of the
+with clause qualifies, and should have the same rules applied. Secondly, we
+don't need the descendant wording for child packages, because they are
+already covered. We do need to cover subunits and child subprogram bodies.
+(We don't allow use of these items in subprogram specifications.) That is
+easy, however, because both are bodies.
+
+So let's try:
+
+  A name denoting a declaration mentioned only in a with_clause which
+  includes the reserved word private shall appear only in a context_clause,
+  body, or private part of a package or generic package. Such a name
+  shall not appear in a use_clause in a context_clause.
+
+"Body" here is the syntactic "body". We could also use "proper_body" here
+(as there is no need to include stubs here, they will always be in a body
+themselves).
+
+This makes C, D, E, F, and H legal, and A, B, and G illegal. Which is what
+we want. It also allows the use of the name in subunits (which are always
+proper_bodys) and in the body of child subprograms. We eliminate making any
+package special, so changing nested packages to child packages or vice versa
+works without change. And the name works in any body in which it is in
+scope, which as it should be.
+
+This has one minor glitch, in that it doesn't allow use in the visible part
+of a private child of the unit. Fixing that:
+
+  A name denoting a declaration mentioned only in a with_clause which
+  includes the reserved word private shall appear only in a context_clause,
+  body, private part of a package or generic package, or private descendant of
+  the unit on which the with_clause appears. Such a name shall not appear in
+  a use_clause in a context_clause.
+
+I'm not quite sure this last is worth it, but it seems necessary for
+consistency.
+
+I'm no fan an enumerating the legal places for a rule, because it is easy to
+forget one. But this seems to be the correct solution to me.
+
+Tuck's "visible place" wording really doesn't simplify this much (if at
+all), it just lets us describe the illegal places. And I'm not quite sure
+how it would work - my first question is "visible to what"? And we'd still
+need the context_clause exceptions. So I don't think that is worth it.
+
+I've updated the AI with this wording; we can discuss it at the meeting or
+via mail.
 
 ****************************************************************

Questions? Ask the ACAA Technical Agent