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

--- ai05s/ai05-0155-1.txt	2009/06/02 04:55:47	1.1
+++ ai05s/ai05-0155-1.txt	2010/06/11 01:49:43	1.2
@@ -1,5 +1,5 @@
-!standard 13.1(23)                                               09-06-01  AI05-0155-1/01
-!class binding interpretation 09-06-01
+!standard 13.1(23)                                   10-06-09  AI05-0155-1/02
+!class ramification 10-06-09
 !status work item 09-06-01
 !status received 09-04-07
 !priority Medium
@@ -9,7 +9,13 @@
 
 !summary
 
-** TBD **
+Only Size clauses with a size greater than or equal to the
+Size that would be chosen by default may be safely presumed
+to be supported on non-static elementary subtypes.
+Implementations may choose to support smaller sizes,
+but only if the Size allows any value of the subtype to be
+represented, for every possible elaboration of the type
+declaration.
 
 !question
 
@@ -19,7 +25,7 @@
     package Pak1 is
         type Integer_32 is range -2**31 .. 2**31-1;
         procedure Proc (Low, High : Integer_32);
-    end Pak1;    
+    end Pak1;
 
     package body Pak1 is
         procedure Proc (Low, High : Integer_32) is
@@ -28,20 +34,30 @@
         begin
             null;
         end Proc;
-    end Pak1;    
+    end Pak1;
 
 Is the 'Size clause legal, requiring a check at runtime to make sure
 there's enough space given the actual values of Low and High; or is it
-illegal? 
+illegal? (It is illegal.)
 
-!recommendation
+!response
 
 (See Summary.)
 
 !wording
 
-** TBD **
+Add after 13.3(56.2):
 
+AARM Ramification:
+
+Only Size clauses with a size greater than or equal to the
+Size that would be chosen by default may be safely presumed
+to be supported on non-static elementary subtypes.
+Implementations may choose to support smaller sizes,
+but only if the Size allows any value of the subtype to be
+represented, for every possible elaboration of the type
+declaration.
+
 !discussion
 
 13.1(23) says that there are no requirements to support representation
@@ -53,7 +69,7 @@
 discrete and fixed point types wuth dynamic constraints is required
 so long as the value is large enough to allow "any value of the subtype".
 
-There seems to be four possible solutions to this problem:
+There seems to be five possible solutions to this problem:
 
 (1) Allow any reasonable value for 'Size, and require a runtime check
 that it fit based on the actual bounds. (similarly for record representation
@@ -86,7 +102,7 @@
         type Integer_32 is range -2**31 .. 2**31-1;
         subtype Sub is Integer_32 range -100 .. 100;
         procedure Proc (Low, High : Sub);
-    end Pak2;    
+    end Pak2;
 
     package body Pak2 is
         procedure Proc (Low, High : Sub) is
@@ -95,7 +111,7 @@
         begin
             null;
         end Proc;
-    end Pak2;    
+    end Pak2;
 
 Requiring support for this case is surely more complex than simply looking at
 the "narrowest" static bounds of an ancestor subtype. (Compilers often use
@@ -109,7 +125,7 @@
       type Disc is (<>);
       Low, High : Disc;
    package Pak3 is
-      type New_Disc is range Low .. High;
+      type New_Disc is new Disc range Low .. High;
       for New_Disc'Size use 16; -- Legal? Rechecked?
    end Pak3;
 
@@ -118,8 +134,16 @@
 
    package New_Pak3 is new Pak3 (Integer_16, 0, 10_000); -- Legal?
 
+(5) Only rely on support for sizes >= Size chosen by default, for
+non-static elementary subtypes.
 
-None of these solutions appears particularly appealing.
+Implementations may already be choosing the minimum possible value
+for Size for non-static elementary subtypes (even though that is
+not specifically required), so using the Size chosen by default
+as an expected minimum supported Size seems reasonable.  In fact,
+many Size clauses for elementary subtypes are specifying sizes larger
+than the minimum Size, and we would still want to allow that.
+Trying to specify a smaller size would not be portable.
 
 --!corrigendum 13.1(23)
 
@@ -146,7 +170,7 @@
     package Pak1 is
         type Integer_32 is range -2**31 .. 2**31-1;
         procedure Proc (Low, High : Integer_32);
-    end Pak1;    
+    end Pak1;
 
     package body Pak1 is
         procedure Proc (Low, High : Integer_32) is
@@ -155,17 +179,17 @@
         begin
             null;
         end Proc;
-    end Pak1;    
+    end Pak1;
 
 Is the 'Size clause legal, requiring a check at runtime to make sure
 there's enough space given the actual values of Low and High; or is it
-illegal? 
+illegal?
 
     package Pak1 is
         type Integer_32 is range -2**31 .. 2**31-1;
         subtype Sub is Integer_32 range -100 .. 100;
         procedure Proc (Low, High : Sub);
-    end Pak1;    
+    end Pak1;
 
     package body Pak1 is
         procedure Proc (Low, High : Sub) is
@@ -174,7 +198,7 @@
         begin
             null;
         end Proc;
-    end Pak1;    
+    end Pak1;
 
 What about this one?
 
@@ -189,7 +213,7 @@
 Date: Wednesday, April  8, 2009  1:24 PM
 
 ...
-> What does "any value of the subtype" mean when the bounds of the 
+> What does "any value of the subtype" mean when the bounds of the
 > subtype aren't known at compile time?
 
 The rules requiring staticness were moved to "Recommended Level of Support".
@@ -197,15 +221,15 @@
 supported.
 
 But there seems to be an intentional hole for elementary types. Why that is is
-totally unclear to me, as it either requires ridiculous implementation hand-stands
-or is totally pointless. (The only representation clause that could reasonably
-required for such a type is a confirming one, which by itself doesn't seem useful
-enough to require.)
+totally unclear to me, as it either requires ridiculous implementation
+hand-stands or is totally pointless. (The only representation clause that could
+reasonably required for such a type is a confirming one, which by itself doesn't
+seem useful enough to require.)
 
 Because of that supposedly intentional hole, we definitely do need to mention
 "non-static" constraints in the recommended level of support for 'Size. (Or we
-need to remove the hole by deleting "composite" from 13.1(23); that would be easier
-but would deal with more than the immediate problem).
+need to remove the hole by deleting "composite" from 13.1(23); that would be
+easier but would deal with more than the immediate problem).
 
 Probably, there should be an extra bullet in 13.3(56.1-3):
 
@@ -213,8 +237,9 @@
 non-static constraints.
 
 That would leave examples like yours completely implementation-defined (without
-banning them outright). Something similar ought to be done for elementary components
-of a subtype with non-static constraints in a record representation clause (it has
-the same issues since the number of bits needed is not known at compile-time).
+banning them outright). Something similar ought to be done for elementary
+components of a subtype with non-static constraints in a record representation
+clause (it has the same issues since the number of bits needed is not known at
+compile-time).
 
 ****************************************************************