CVS difference for ai05s/ai05-0135-1.txt

Differences between 1.3 and version 1.4
Log of other versions for file ai05s/ai05-0135-1.txt

--- ai05s/ai05-0135-1.txt	2009/02/10 06:50:26	1.3
+++ ai05s/ai05-0135-1.txt	2009/02/13 03:10:54	1.4
@@ -1,4 +1,4 @@
-!standard  4.1.3(12)                                   09-02-06    AI05-0135-1/01
+!standard  4.1.3(12)                                   09-02-11    AI05-0135-1/02
 !standard  8.4(3)
 !standard  8.4(4)
 !standard  8.4(8/2)
@@ -30,9 +30,85 @@
 exported this way, so additional renaming or declarations are required to
 completely make the instance transparent.
+This use of a derived type is really something of a kludge.
+What is really wanted here is a way to make all of the
+declarations declared in the instantiation visible as if
+they were declared at the same level as the instantiation
+(as opposed to within it).
+A different, but related, problem has to do with a desire to
+make more declarations visible via a use_type clause.
+Given a subtype name (which is often declared in a different
+declarative region than the first named subtype of the type in
+question), an existing "use type S;" clause provides use-visibility
+of the primitive operators of S. It is often the case that more
+is wanted - use-visibility of other primitive subprograms (notably
+enumeration literals) and, in the case of a tagged type, subprograms
+which operate on the corresponding classwide type.
+Solving these two problems via two separate mechanisms would introduce
+too much syntactic complexity. These problems need to be solved
+via the addition of a single new construct.
+Define a syntactically new form of use clause by allowing the
+(optional) reserved word "all", as in
-** TBD ** Define a kind of transitive use clause.
+    use all Pkg1, Pkg2;
+    use all type T1, T2;
+Adding the reserved word "all" gives the use clause the following
+new effects on visibility:
+   1) If the use clause occurs in the visible part of a package, then
+      the items that would be made use-visible by a "normal" use_clause
+      are also made visible as if they were declared in the visible part
+      of the given package. A new form of use visibility, "use-visibility
+      by selection", is defined.
+      For example,
+        declare
+          package Pkg1 is
+            X : Integer := 0;
+          end Pkg1;
+          generic
+          package G is
+            Y : Integer := 0;
+          end G;
+          package Pkg2 is
+            use all Pkg1; -- makes "Pkg2.X" visible
+            package I is new G;
+            use all I; -- makes "Pkg2.Y" visible
+            Z1 : Integer := X + Y;
+            package Inner is
+              X, Y : Float;
+              Z2 : Integer := Pkg2.X = Pkg2.Y;
+            end Inner;
+          end Pkg2;
+          Ren1 : Integer renames Pkg2.X;
+          Ren2 : Integer renames Pkg2.Y;
+          use Pkg2;
+          Ren3 : Integer renames X;
+          Ren4 : Integer renames Y;
+        begin
+          null;
+        end;
+   2) In the case of a use_type_clause, the reserved word "all" causes
+      more subprograms to become use-visible. These include all
+      primitive subprograms of T (not just the primitive operators)
+      and, in the case of a tagged type, the "primitive subprograms"
+      of T'Class (ignoring for purposes of discussion the fact that
+      this notion isn't really defined).
@@ -113,10 +189,161 @@
+One of the solutions that is currently being discussed for the
+"declare a private type, use it to instantiate a generic, and
+export the instance" problem is the "deferred instance body elaboration"
+The original motivation for this "reexporting use_clause" proposal was to
+make the "deferred instance body elaboration" proposal more attractive
+by allowing something like
+    with Some_Container_Generic;
+    package Pkg is
+      type T is private;
+      package I is new Some_Container_Generic (T);
+      use all I;
+    private
+       ...
+    end Pkg;
+    with Pkg;
+    package Client is
+      X : Pkg.Valise; -- the name Pkg.Valise denotes Pkg.I.Valise;
+    end Client;
+That is why the example given in the Example section of the 
+wording involves an instantiation, albeit one that does not
+involve passing in a non-yet-completed private type as an
+actual parameter.
+The use_type_clause-specific part of the proposal is completely
+orthogonal to the rest. One could imagine different syntax for
+this and then having all 4 forms of use_type_clause, as in
+    use type T;
+    use all type T;
+    use type T with all of interface; -- or whatever
+    use all type T with all of interface;
+, but this seems like overkill. The use_type_clause-specific part
+of this proposal is motivated by a desire to be able to use a
+subtype name to make more than just the primitive operators of the
+type use-visible (e.g., enumeration literals).
+    package Pkg1 is
+      type Enum is (Aa, Bb, Cc);
+      function Foo (X : Enum) return Integer;
+    end Pkg;
+    with Pkg1;
+    package Pkg2 is
+      subtype S is Pkg1.Enum;
+    end Pkg2;
+    with Pkg2; -- no with of Pkg1
+    package Pkg3 is
+      use all type Pkg2.S;
+      X : Integer := Foo (Aa);
+    end Pkg3;
+The language has no notion of a use_clause (which is not a declaration)
+being visible or not. The closest thing in the language to visibility
+for a non-declaration is the streaming attribute availability stuff
+for limited types, but that's not applicable to use clauses.
+This means that we have to be careful in the wording not to open the door
+for something like
+    package P is
+      X : Integer;
+      package Q is
+        Y : Integer renames Q.X; -- illegal
+        use all P;
+      end Q;
+    end P;
+and other more convoluted examples.
+That's why the wording includes a "notwithstanding" clause. The visible
+part of Q includes a use all clause which will eventually make the
+declaration of P.X visible via the name Q.X, but this hasn't happened
+yet at the point where the name Q.X is being resolved and the wording
+needs to somehow reflect this.
+A "use all" clause affects name resolution of direct names
+and expanded names.
+The legality of
+    declare
+      package P is
+        X : Integer;
+      end P;
+      package Q is
+        use all P;
+      end Q;
+      use Q;
+      Y : Integer renames X;
+    begin null; end;
+follows from the rule that the scope of the first use clause
+includes the scope of the second. This illustrates how the
+resolution of a direct name may be affected.
+The bulk of the wording deals with the case of an expanded name,
+which is illustrated by the example in the !proposal section.
+Note that in resolving an expanded name, we make use of the
+existing definition of "potentially use-visible", but not that
+of "use-visible". The definition of "use-visible" does whatever it
+does in this case, but no language rule depends on the result.
+The notion of "use visibility by selection" is defined
+in terms of the set of declarations that are "potentially use-visible",
+but the set of "use-visible" declarations plays no role here. 
+Note that the with of a child unit may add a declaration to the
+visible part of the parent unit and thereby hide a declaration
+which otherwise would have been use-visible. For example,
+   package Pkg is
+     Child : Integer;
+   end Pkg;
+   with Pkg;
+   package Parent is
+     use all Pkg;
+   end Parent;
+   with Parent;
+   package Client1 is
+     X1 : Integer renames Parent.Child;
+   end Client1;
+   package Parent.Child is
+   end Parent.Child;
+   with Parent.Child;
+   package Client2 is
+     package X2 renames Parent.Child;
+   end Client2;
+This means that one can never refer to the set of visible
+declarations declared in a package spec as though it were
+an immutable set (at least as seen from outside of the package).
+The wording must always be in terms of the set of declarations that
+are visible at some particular point in the program.
+In hindsight this is probably obvious.
-(See wording.)
+(See other sections.)
 --!corrigendum 8.4(3)

Questions? Ask the ACAA Technical Agent