CVS difference for ais/ai-00366.txt

--- ais/ai-00366.txt	2004/02/21 04:15:11	1.4
+++ ais/ai-00366.txt	2004/04/06 19:57:16	1.5
@@ -1,4 +1,4 @@
-!standard 10.2.1                                     03-12-14  AI95-00366/01
+!standard 10.2.1                                     03-12-14  AI95-00366/02
 !class amendment 03-12-14
 !status work item 03-12-14
 !status received 03-12-14
@@ -8,7 +8,7 @@
 
 !summary
 
-Pure units allow access-to-subprogram tyes and access-to-object types,
+Pure units allow access-to-subprogram types and access-to-object types,
 for which no storage pool is created.
 
 !problem
@@ -18,6 +18,9 @@
 There is no technical reason for the restriction and many packages
 that should be pure can not be declared pure.
 
+Similarly, generic formal access types should be permitted (as the storage
+pool comes from outside of the unit).
+
 !proposal
 
 (see wording)
@@ -65,6 +68,75 @@
 
 !appendix
 
+!topic Generic formal access types in Pure packages
+!reference 10.2.1(16)
+!from Adam Beneschan 11-27-02
+!discussion
+
+
+Is it the intent of 10.2.1(16) that a Pure package cannot declare a
+nested generic with a generic formal access type?
+
+Specifically, I believe the RM makes these two package declarations
+illegal:
+
+-- (1)
+package pak1 is
+   pragma Pure;
+   generic
+      type T1 is private;
+      type T2 is access all T1;
+   package genpack is
+      procedure proc (x : in T2);
+   end genpack;
+end pak1;
+
+-- (2)
+package pak1 is
+   pragma Pure;
+   generic
+      type T1 is private;
+      type T2 is access all T1;
+   procedure proc (x : in T2);
+end pak1;
+
+10.2.1(16) says, "A pure library_item is a preelaborable library_item
+that does not contain the declaration of any variable or named access
+type, except within a subprogram, generic subprogram, task unit, or
+protected unit".  Both of these packages contain declarations of named
+access types named T2.  I can't find anything in the RM that would
+make declarations of generic formal types *not* fall under this rule;
+the declaration of a generic formal type is clearly a "declaration",
+and from everything I can tell, a generic formal type is a "type".
+(In case (2), although the type declaration is within a
+generic_subprogram_declaration, I don't think this is the same thing
+as being "within a ... generic subprogram".)
+
+However, my impression (which may be off base) is that the rule is
+intended to prevent Pure packages from declaring new access types, and
+a generic formal type doesn't fit this description.  So should
+10.2.1(16) be amended to exclude generic formal access types?
+
+By the way, GNAT accepts both of the above examples.
+
+****************************************************************
+
+From: Christoph Grein
+Sent: Wednesday, November 27, 2002  11:48 PM
+
+Also Rational Apex 3.2.0b accepts them.
+
+****************************************************************
+
+From: Pascal Leroy
+Sent: Thursday, November 28, 2002   3:12 AM
+
+I think that the two examples should be legal, and that the wording in
+10.2.1(16) is lousy.  It would probably be good to fix it, although I would see
+this as a low priority issue.
+
+****************************************************************
+
 From: Randy Brukardt
 Sent: Tuesday, February 3, 2004  5:16 PM
 
@@ -1148,5 +1220,46 @@
 Making Text_IO preelaborated is far too big a change, it might result in
 a need for a radical reimplementation. There is simply nothing to justify
 such a huge change.
+
+****************************************************************
+
+From: Pascal Leroy
+Sent: Tuesday, March 16, 2004  7:30 AM
+
+A quick note following the discussion of AI 366 at the last meeting:
+imported objects should be excluded from the restrictions in 10.2.1(9),
+as no initialization takes place for these objects (B.1(38)).  This
+change would make it possible to write preelaborable units that
+reference objects exported from the runtime system.  Not that any user
+would want to do that, but implementers might want to do it, for
+instance to implement some of the "Alan packages".
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Saturday, March 20, 2004  7:54 PM
+
+Well I am dubious about the idea of semantics that are useful
+only for implementors, but if this is the case, implementors
+can do anything they like anyway within the run time library,
+since it does not have to be in Ada at all.
+
+****************************************************************
+
+From: Robert A. Duff
+Sent: Sunday, March 21, 2004  11:35 AM
+
+True, but why force implementors to have (another?) special case in
+their compilers, of the form "if we're compiling the run-time system
+then ... else ... end if;"?
+
+Anyway, I'm not sure I believe that the proposed rule is useful only for
+implementors.  Pascal pointed out one usage (which is for implementors),
+but the feature in question is harmless and natural, and therefore might
+be useful for anybody.
+
+The wording of 10.1.2(9) talks about a "default-initialized object",
+so it seems pretty silly to forbid imported objects, since they
+are not, in fact, initialized by default.
 
 ****************************************************************