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

--- ai05s/ai05-0155-1.txt	2010/06/11 01:49:43	1.2
+++ ai05s/ai05-0155-1.txt	2010/06/11 02:03:00	1.3
@@ -1,4 +1,4 @@
-!standard 13.1(23)                                   10-06-09  AI05-0155-1/02
+!standard 13.1(23)                                   10-06-10  AI05-0155-1/03
 !class ramification 10-06-09
 !status work item 09-06-01
 !status received 09-04-07
@@ -55,8 +55,7 @@
 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.
+represented, for any possible value of the bounds.
 
 !discussion
 
@@ -243,3 +242,91 @@
 compile-time).
 
 ****************************************************************
+
+From: Tucker Taft
+Date: Wednesday, June  9, 2010  1:15 PM
+
+Here is a "ramification" writeup of the AI relating to 'Size on non-static
+scalar subtypes. I didn't find the minutes as useful as I had hoped, and wasted
+an inordinate amount of time on something that will almost certainly have no
+effect on any implementation. In any case, here it is. [This is version /02 of
+the AI.]
+
+The main conclusion I had was that users should be allowed to specify a
+confirming or larger Size for a non-static elementary subtype, but not
+necessarily a smaller Size. In some implementations, the confirming Size is
+already as small as the implementation will support, even for non-static
+subtypes.
+
+I also came down on the side of making the Size clause legal only if it would be
+legal in every possible elaboration of the type. Hence, if the subtype bounds
+are dynamic, then an implementation may assume the "worst" when deciding whether
+a specified Size is adequate, rather than expecting a run-time check during
+elaboration of the type to be sure the specified Size is adequate, which
+probably wouldn't be doing anyone any favors.
+
+****************************************************************
+
+From: Steve Baird
+Date: Wednesday, June  9, 2010  2:04 PM
+
+> ... for every possible elaboration of the type declaration.
+
+Using the phrase "every possible elaboration" in RM wording with no further
+clarification of what this means seems odd. In addition, I just generally don't
+like linking legality rules to dynamic semantics.
+
+Maybe it is ok in this case; I don't see how it can cause any problems.
+
+For example, I suppose it would be ok if a peculiar implementation chose to
+accept something like
+
+     declare
+        procedure Never_Called (Lo, Hi : Integer) is
+            type T is new Integer range Lo .. Hi;
+            for T'Size use 1;
+        begin null; end Never_Called;
+
+        Untrue : Boolean := False;
+     begin
+        if Untrue then
+            Never_Called (Lo => Integer'First, Hi => Integer'Last);
+        end if;
+     end;
+
+It may be that there is no problem here, but I think it deserves review.
+
+****************************************************************
+
+From: Tucker Taft
+Date: Wednesday, June  9, 2010  2:04 PM
+
+I agree this is somewhat weird.  We could say "any possible value of the bounds,
+if non-static."  That falls back on the "any possible value" which is already
+used (and not well defined ;-).
+
+****************************************************************
+
+From: Randy Brukardt
+Date: Thursday, June 10, 2010  2:04 PM
+
+It's an AARM note, so it doesn't need to be that well-defined. :-) The use of
+"may be" is iffy (but OK because it's an AARM note).
+
+Anyway, I don't see much need for the "if non-static" here. If the bounds are
+static, "any possible value of the bounds" is a single value; otherwise, they
+are whatever they are. Besides the first sentence says that we are talking
+mainly about non-static subtypes. Here's the revised paragraph again:
+
+  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 any possible value of the bounds.
+
+Anyway, I made this change, so hopefully we can dispose of this AI quickly when
+it comes up.
+
+****************************************************************
+