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

--- ai05s/ai05-0190-1.txt	2009/12/09 01:20:40	1.2
+++ ai05s/ai05-0190-1.txt	2010/02/25 00:55:13	1.3
@@ -1,4 +1,4 @@
-!standard D.7(8)                                09-11-19  AI05-0190-1/02
+!standard D.7(8)                                10-02-24  AI05-0190-1/03
 !class amendment 09-11-03
 !status work item 09-11-03
 !status received 09-11-03
@@ -39,17 +39,17 @@
 
                                    Syntax
 
-The form of a pragma No_Default_Storage_Pool or Default_Storage_Pool is as
-follows:
+The form of a pragma Default_Storage_Pool is as follows:
 
-    pragma No_Default_Storage_Pool;
-    pragma Default_Storage_Pool(*storage_pool*_name);
+    pragma Default_Storage_Pool(storage_pool_indicator);
 
-A pragma No_Default_Storage_Pool is a configuration pragma.
-A pragma Default_Storage_Pool is allowed at the place where a declarative_item
-is allowed.
+    storage_pool_indicator ::= *storage_pool*_name | null
 
+A pragma Default_Storage_Pool is allowed immediately within the visible part of
+a package_specification, immediately within a declarative_part, or as a
+configuration pragma.
 
+
                             Name Resolution Rules
 
 The *storage_pool*_name is expected to be of type Root_Storage_Pool'Class.
@@ -58,30 +58,58 @@
                                 Legality Rules
 
 The *storage_pool*_name shall denote a variable.
+
+If the pragma is used as a configuration pragma, the storage_pool_indicator
+shall be null, and it defines the "default pool" to be null within all
+applicable compilation units (see 10.1.5), except within the immediate scope of
+another pragma Default_Storage_Pool. Otherwise, Redundant[the pragma occurs
+immediately within a sequence of declarations], and it defines the default pool
+within the immediate scope of the pragma to be either null or the pool denoted
+by the *storage_pool*_name, except within the immediate scope of another pragma
+Default_Storage_Pool. Redundant[Thus, an inner pragma overrides an outer one.]
+
+A pragma Default_Storage_Pool shall not be used as a configuration pragma within
+the immediate scope of another such pragma.
+
+    AARM Rationale: This is to prevent confusion in cases like this:
+
+        package Parent is
+            pragma Default_Storage_Pool(...);
+            ...
+        end Parent;
+
+        pragma Default_Storage_Pool(...); -- Illegal!
+        package Parent.Child is
+            ...
+        end Parent.Child;
+
+   where the Default_Storage_Pool on Parent.Child would not (if it were legal)
+   override the one in Parent.
 
-A Default_Storage_Pool shall not be within the immediate scope of another
-Default_Storage_Pool.  [???Or should the inner/later one override the other?
-Sounds complicated, wording-wise and implementation-wise.]
 
                               Static Semantics
+
+For an access type to which no Storage_Pool nor Storage_Size clause applies:
+
+    If the default pool is null, the Storage_Size attribute is defined
+    by the language to be zero.
+    Redundant[Therefore, an allocator for such a type is illegal.]
 
-Within the immediate scope of a pragma Default_Storage_Pool, the Storage_Pool
-attribute of any access type to which no Storage_Pool nor Storage_Size clause
-applies is defined to be the pool denoted by the *storage_pool*_name.
-
-If No_Default_Storage_Pool applies to a given compilation_unit, then any access
-type within that compilation_unit that has neither a specified Storage_Pool nor
-Storage_Size is defined by the language to have a Storage_Size of zero.
-[Therefore, an allocator for such a type is illegal.]
+    If the default pool is a pool, the Storage_Pool attribute is that
+    pool.
 
-    AARM: This implies that Default_Storage_Pool trumps
-    No_Default_Storage_Pool.
+    Otherwise, Redundant[there is no default pool]; the Storage_Pool
+    attribute is implementation defined.
 
+AARM Ramification: Default_Storage_Pool is the only way to specify the storage pool for an anonymous access type.
+
+If an object has a coextension, the coextension is always allocated in the same pool as the object.
+
 !discussion
 
 Expected usage scenarios are:
 
-    - No_Default_Storage_Pool as a configuration pragma applying to the whole
+    - Default_Storage_Pool(null) as a configuration pragma applying to the whole
       program.
 
       To use an allocator for an access type, you have to apply a Storage_Pool
@@ -92,7 +120,8 @@
       subsystem.
 
       This default pool is used within the package and its children,
-      but you can override it with a Storage_Pool or Storage_Size clause.
+      but you can override it with a Storage_Pool or Storage_Size clause,
+      or with another Default_Storage_Pool.
 
 !example
 
@@ -330,5 +359,73 @@
 because none would be visible. But there would be no problem with giving "null"
 in that usage. So only one pragma is needed, and there is no need to worry about
 what happens when they conflict.
+
+****************************************************************
+
+From: Bob Duff
+Sent: Wednesday, February 24, 2010  2:01 PM
+
+New version of AI05-0190-1.
+
+In the phone meeting, we said we didn't like allowing multiple
+Default_Storage_Pools immediately within a single sequence of declarations, and
+we said they should be at the start.  But that seems overly restrictive, and I
+don't think the wording is that hard.  Seems like we want to allow:
+
+    with ...;
+    package P is
+        My_Pool : ...;
+        pragma Default_Storage_Pool(My_Pool);
+        type T1 is access...;
+        type T2 is access...;
+    end P;
+
+And it seems harmless and useful to allow:
+
+    with ...;
+    package P is
+        My_Pool : ...;
+        pragma Default_Storage_Pool(My_Pool);
+        type T1 is access...;
+        Other_Pool : ...;
+        pragma Default_Storage_Pool(Other_Pool);
+        type T2 is access...;
+    end P;
+
+So I wrote this wording:
+
+   If the pragma occurs immediately within a package_specification or
+   declarative_part, it shall precede all declarative_items (other than other
+   pragmas).
+
+   Only one such pragma is allowed immediately within a given sequence
+   of declarations.
+
+and then deleted it.  I'm including it here for the record.
+
+
+The new wording and discussion sections are below; the rest of the AI remains
+unchanged. [This is version /03 of the AI - Editor.]
+
+P.S. I hate the way configuration pragmas work!
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Wednesday, February 24, 2010  6:45 PM
+
+I don't see any wording in here defining where these pragmas apply. You seem to
+assume that it is scoped like Suppress, but that doesn't happen automatically;
+there has to be some words like 11.5(7.1-2/2) somewhere.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Wednesday, February 24, 2010  6:52 PM
+
+Sorry. Found it in the Legality Rules. It was formatted as all one long line,
+and didn't see that it was out to character 700. It seems weird to have it in
+Legality Rules (it's a definition and seems to belong in Static Semantics), but
+that isn't a huge issue.
 
 ****************************************************************